Re: [address@hidden: GSoC proposal, device driver glue code]

[Anastassios A. Nanos]

at first, thank you all for you kind comments and for the time you spent 
reading my proposal.

I will try to be as precise as possible.

> Something missing in this proposal is how to deal with runtime changes, 

> especially for USB devices. 

that's true. there are a lot of things missing mostly because the 
proposal is a bit vague and generic. This is due to the fact that there 
are issues with GNU/Mach I'm not familiar with but eager to study and learn.

> There were a lot of changes between Linux 2.4 and 
> 2.6, but most of them were related to dynamic configurations and SMP systems. 
> IIRC, GNU Mach initializes devices only at boot time, so this requires huge 
> effort on the design.

I agree, but as i said previously the generic form of the proposal 
allows to restrict such issues and concentrate on basic intergration of 
block device drivers (that means having a computer with semi-modern 
configuration run the hurd). USB is an issue but even if USB support can 
be only initialized at boot time, that could be a start;-)

> But this might be a bit overkill for SoC. Only replacing drivers with newer 
> ones is also worth doing, so it might be better to focus on a narrow range.

I agree. I'm rephrasing my proposal focusing on updating block and 
network device drivers that already exist, and if it is robust enough 
then we can extend GNU/Mach's support.

> I like this proposal but I also have a question : did you consider BSD
> drivers ? I understand you have experience with Linux drivers, and this
> is a very good reason to work on a glue code for them, but from what I
> could see (at least this was true with earlier version of Linux), there
> were device drivers tightly related to some kernel internals (the
> example I have in mind is some drivers directly accessing mem_map, which
> could not be emulated in a glue code).
> BSD has common roots with Mach, which may make BSD drivers integration
> simpler. For example, the VM and waiting/locking primitives are quite
> similar.

My experience with BSD device drivers is little (if not none). I have no 
knowledge if *BSD kernels are similar to Mach or not, though I intend to 
study GNU/Mach and figure out similarities or possible integrating parts 
from the Linux Kernel;-). I intend to work with the Hurd not only for 
GSoC but for my own (or the community's) satisfaction. So if it is 
possible to study BSD / GNU/Mach's similarities (outside SoC) and 
redesign (or better, help to redesign) a different model for device 
integration, I would love to be a part of this task. Even if there is a 
slightest chance of me contributing to GNU/Mach's development I would 
love to get to work for the Hurd.


A way to boost my knowledge and experience with the Hurd and making work 
have a point, is by and large trying to "construct" a GSoC proposal (not 
the only way of course, but i think it's a good start). Having to study 
to commit such an application gave(gives) me the opportunity to get to 
know the Hurd better and be able to see if I can contribute something or 
not. My intend to help isn't as restricted as a GSoC proposal.


I'm currently updating my proposal, I think comments are never enough .. 
so if you have something please feel free to send;-)
According to the schedule I have, I will submit the application on 
Sunday (hope it's now too late;-))

Thank you again for your kind attention and comments.

A.N.