Neal H Walfield wrote:
> > So, I propose that we have 3 files: device.c, device_linux.c, device_gnu.c
> > (BTW, why not device_hurd.c?)
>
> I imagine both are reasonable and hurd might in fact be better as we
> target the services provided by the hurd and not the whole system.
> If we targeted the whole system, then I would prefer device_linux_gnu.c
> or some such and device_gnu.c.
OK. Well, device_linux.c isn't ambiguous, and device_linux_gnu.c
is getting a bit long for my liking. If anyone gets confused, I'll
change it.
> As you are doing the long term maintaining, I leave this in your hands,
> however, I have one primary concern: what happens when we have another
> port? Which is to say, someone ports to a BSD. The BSD port could share
> 50% of the Linux code. In your model, I see cutting and pasting.
Yes.
> In
> the libc model, we continue with the sysdeps abstraction and create a
> generic repository.
I prefer cut&paste, because:
* it's a small amount that gets cut&pasted (probably < 300 lines)
* it makes it easier to see how the different parts interact
There's another thing: there tends to be subtle differences
on different platforms, in this "shared code". For example,
it's likely that we'll need a special ioctl on Linux to access
the last (size % block_size) bytes of a block device.
So, trying to handle "common code" when they aren't EXACTLY
common means you get a mess of #ifdef's, or whatever.
Some ppl get "cut&paste is a cardinal sin" drilled into them.
I don't buy it. (My position seems to be shared by people
in the linux world, but not the gnu world)
> As for the naming scheme, I do not like it at all. _arch_* and _ped_*
> should be unified. What happens when a new port forces _ped_foo ()
> to change to _arch_foo? Grep?
The idea is that _ped_foo() is portable. i.e. completely abstract.
So no _ped_foo() will never ever need to be changed to _arch_foo().
Thanks,
Andrew Clausen
P.S. Even though I don't like your design that much, your code
is still going to be very useful - just a matter of rearranging
it a bit :-) I appreciate you work.
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
