Re: plan to work on user-level device drivers

[Da Zheng]

Thomas Schwinge wrote:
> Confirmed.  Neither is it (it's part of the ``Proceedings of the USENIX
> Mach III Symposium'', by the way) available at my university's library or
> another library nearby.
>
> Options:
>
>   * Thomas, Roland (CCed): Do you have a copy somewhere?
>
>   * Send email to the authors, asking for a copy.
>
>   * Send email to other authors who referenced it, asking for a copy.
>   
It works. I have got a copy:-)
I wonder where I can upload it to?
> > My plan is to write a user-level device driver for testing and ideally, 
> > to port ddekit to Mach if it is possible.
> > The first device I choose will be ethernet card, which I think is the 
> > one I relatively familiar with.
> > Any suggestion is welcome!
> >     
>
> I would start with something much simpler.  Something that does not even
> involve PCI.  For example, continue to work on the user-space keyboard
> driver that I linked to on the user-space_device_drivers page.  Or even
>   
Continuing working on the user-level keyboard driver should be a good 
approach for now and I am trying this direction.
> simpler, begin with something that really only sends a message to a
> user-space server when an interrupt occurs (from the keyboard, for
> example, or serial line (mouse); for now additionally to handling that
> interrupt in the kernel driver), work out how user-space servers can
> register as receivers for interrupts, stuff like that.  Have a look at
> the Omega0 paper I linked to from the same web page.  I think (if I
> recall correctly from having read it two years ago) it has a nice summary
> of how the PC IRQ system works, and how to deal with that in a
> microkernel system.  Also, as you noticed in the ``An I/O System for Mach
> 3.0'' paper, such stuff should already be part of the (of *some*) Mach
> code base.  I have no idea whether it's in GNU Mach.  Actually, I just
> had a look and here is my very quick analysis: interrupts are handled in
> i386/i386at/interrupt.S:interrupt, from where it is diverted to the
> registered handler as specified in ivect.  This one is originally defined
> in i386/i386at/pic_isa.c and later modified (according to run-time device
> registrations during booting) in i386/i386at/autoconf.c:take_dev_irq and
> take_ctlr_irq (the latter being obsolete, it seems),
> i386/i386at/kd_mouse.c and linux/dev/arch/i386/kernel/irq.c.  No sign of
> anything that would allow for registering a user-space server for
> receiving interrupt messages.  But perhaps I've been looking at the wrong
> place.  Perhaps there are some Mach sources in the FTP repositories that
> include such things?
>   
I read the relevant code in Mach 3, but didn't find the simple interrupt 
handler for Ethernet driver in the kernel.
And I download , but again I didn't find the user-level Ethernet driver 
in it.
Maybe I missed something.
> That aside, I still don't know if a NIC is the most easy thing to begin
> with.  What also could be done, and what I had in mind for a long time
> already, is a simple driver for a SoundBlaster ISA card (again, no PCI
> for now -- I don't know if PCI device registration actually is difficult,
> but let's simply avoid that for now).  I think that QEMU and friends can
> still emulate such ISA sound cards.  And then: there are quite a few
> Minix 2 and Minix 3 papers that describe the design and implementation of
> exactly such servers for Minix.  Perhaps we can even use their code.
> (Minix 3 being the most valuable candidate, of course.)  Also have a look
> what they're doing in general for delivering IRQs, and setting up DMA,
> etc.  Or, you could have a more detailed look at what the L4 people are
> doing: are there some paper that reference the Omega0 one, perhaps?
>   
I know almost nothing about sound card. Maybe I can try it after I 
finish the user-level keyboard.

Zheng Da