GSOC Userland PCI drivers (possible duplicate)

[Pedro Falcato <pedro.falcato%gmail.com@localhost>]

Hi,

Sorry if it's a duplicate, but I've sent this once and it wasn't
received by the mailing list, so here I go again.

My name is Pedro Falcato and I'm a student from FCT Nova, Lisbon,
Portugal. I've been looking at your projects for GSoC, and I've been
particularly interested in the Userland PCI drivers idea you mentioned
in the projects' section in the wiki. Admittedly, I don't have
experience working with BSD but over the years I've successfully
developed my own hobby OS which means I've got plenty of experience
working with kernel code and PCI in general, from both personal
experience and looking at other kernels.

So, after playing around with NetBSD for a bit and reading the
project's details, I've got a few questions:

1) Right now, PCI devices are exposed in /dev sequentially. Is it
possible to expose them elsewhere? When I originally looked at the
project, I thought about doing something similar to Linux where you
get your device as a directory and each property of the device is
exposed as a file(for example, BAR0 is exposed as resource0, etc). Is
this not an option, or is it not favoured in the NetBSD design? The
other idea I had was to generate a fake offset(or use the BAR number
straight up) in an ioctl() and mmap it, but I'm not sure if
/dev/pciN's mmap is already used for something else.

2) When you mention events when exposing you mean they would be
received by code similarly to a (select/poll/kqueue) loop plus a
read/ioctl, correct?

3) How would a driver receive a request from another process/the
kernel? Another ioctl()?

4) How would a driver know where to DMA to? As in, how does the kernel
pass in the page addresses? Is there a mechanism in place to do that?

Looking forward to working with you!

Pedro Falcato