dslinux/linux-2.6.x/drivers/mmc scsd_c.c scsd_s.S

[Amadeus]

Malcolm,

On Sunday 27 August 2006 23:31, Malcolm wrote:

[plugin interface for various devices in scsd_c.c]

> I specifically told you not to do this.

Yes, I remember... 

> The MMC layer handles using different drivers for different devices.

Yes, but this would mean to duplicate about 50% of the driver code.
Each time a new card is added. Why?

I want to set up a common build for all RAM-capable cards now, and for 
this goal, code sharing makes sense to me.

> Also "Structure for device-specific functions in assembler."
> "in assembler"?!
> Don't write an M3SD driver in assembler.

IMHO, this is the best way to go for the lowlevel interface.

Writing these drivers in assembler gives you some benefits not possible 
in C.

- Speed. Movement of data is faster if you code the central loops in 
assembler. Because in the RAM-based builds, all userland lives on 
CF/SD, speed is an important factor for DSlinux here. If you loose time 
for GBA ROM/IO switching, it is importend to limit these time losses as 
most as possible. In the development of the new driver, speed issues 
were clearly visible to me.

- Control. In assembler, you can control the usage of the stack and 
stack-based local variables. In C, you can not. As in the RAM-based 
builds, the stack will(!) be in GBA ROM space, it is mandatory to block 
stack accesses if GBA ROM space is switched to IO.

Sorry if you don't like what I do. For me, using the most suited 
language for each task is natural behaviour, if you must go to the 
limit. I am aware that some programmers have strong objections for 
choosing languages, or avoiding gotos, or else. I feel uncomfortable 
with this.

So what can we do to improve the situation?

First of all the stack situation: I think it will be good if the kernel 
stack is in main memory for all builds, because of speed. Do you know 
how to achieve this? This will open the door to C-based "switching" 
drivers, and the only cause for writing assembler will be speed, so 
assembler parts may be much smaller.

Second, my goal was to "test" the new plugin interface by writing a 
driver for the M3SD. Only by testing, I will find out how much of the 
common code is in fact common. Maybe I have to abandon the plugins, but 
I don't know now.

I have got new and extended code for the M3SD, in the libfatdragon lib 
(from DSORGANIZE), and I think it is better now to write a driver.

What do you think?

regards
Amadeus

-- 
We're back to the times when men were men 
and wrote their own device drivers.

(Linus Torvalds)