Re: [alliance-iosk] Comments on IOSK LM spec

[vhandel@chem.vu.nl (Ramon van Handel)]

>To avoid all risks, if it is present a function named LMinitHW inside the LM
>code, the LM loader will look for that, and execute only once in LM lifetime
>after LMinit(). Agree?

Why would you do that ?  If you want that, I think the cleanest solution is
to simply put the HW init code in LMinit().  What's wrong with that ?

>> Another little thing about the directory naming:  you put the parallell
>> port LM in a directory called ibm-pc.  Now in principle, we should divide
>> hardware drivers per hardware platform, but in practice hardware platforms
>> are not as unambiguous as processors.  For instance, the IBM-PC compatibles
>> as well as the Digital Alpha, and perhaps also sparcs and macs (not sure)
>> use the same serial 16650 UART and parallell port hardware.  If you divide
>> on the basis of ibm-pc, that would mean inefficient code reuse.
>
>I have thinked about this over and over, and these are my ideas:
>
>hardware is sometimes equal, but this overlap occurs only (in my knowledge) to
>keyboard, serial and parallel ports and IDE disks.

How do you know that this is going to stay ?  I don't think you can tell...

>Well, the problem is: how much they are equal?
>If you see the Linux kernel code, you'll see a lot of ifdef of this and that
>hardware to differentiate the slightly different behaviour of the same chip.
>They are not so equal as you may think. Also this implies that a modification
>done on one platform can made the LM of another environment unstable, and this
>is bad. Also this made LM writing more difficult, and I wish to made it the
>easier process possible.
>Another point is that (from the device driver implementor point of view) the
>other platform don't exists. He focus on one platform, then (if needed) to
>another one.
>Timing considerations are much different from one platform to another, and so
>needed optimizations.
>Generally speaking, a device driver implementor knows exactly that a particular
>device is used by others, so he can include code, if needed.
>Roughly speaking, a few overlaps will occur, say 3 items will be replicated in
>each hardware tree (for IOSK at least).

Okay, keep it the way it is.  I'm still not very convinced, but it'll do at
least until it presents any problems.

>> Anyway, for the rest, I think it's a great spec !!!  Now you just need to
>> get it to actually work together with the IOSK.
>
>Tell me (for my curiosity) what do you like more. I have my "loved"
>points, and
>I wish to see which are yours.

Do you mean what parts I liked best ?  I like the probe string and the BNF
diagram, smart piece of work that :)

>I have a lot of work ahead ;).

We all do.

>PS: I have read CK code. I'll ask you something in the near future....

Shoot.

Ramon



---
Ramon van Handel   <vhandel@chem.vu.nl>
Chemistry Student, OS Programmer and all-round Weirdo
The ant has made himself illustrious / Through constant industry industrious.
So what? Would you be calm and placid / If you were full of formic acid?
(Ogden Nash)


-
Alliance-IOSK:	http://iosk.allos.org/
Archive:	http://humbolt.nl.linux.org/lists/