bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anastassios A. Nanos
Subject: Re: [address@hidden: GSoC proposal, device driver glue code]
Date: Sat, 24 Mar 2007 00:39:51 +0200
User-agent: Icedove 1.5.0.9 (X11/20061220)

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]