dslinux/linux-2.6.x/drivers/mmc scsd_c.c scsd_s.S
amadeus at iksw-muees.de
Mon Aug 28 12:03:36 CEST 2006
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
- 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
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?
We're back to the times when men were men
and wrote their own device drivers.
More information about the dslinux-devel