dslinux/linux-2.6.x/drivers/mmc scsd_c.c scsd_s.S
Amadeus
amadeus at iksw-muees.de
Mon Aug 28 12:03:36 CEST 2006
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)
More information about the dslinux-devel
mailing list