Comments from a newbie kernel hacker... ;-)
> Device hierarchy
> ~~~~~~~~~~~~~~~~
> The kernel should have some central data structure describing all known
> devices, buses and their hierarchy.
>
> Basically, most of the device data structure is bus-dependent, but
> there is some generic info like pointer to bus_operations (a struct
> containing pointers to common operations like virt_to_bus which need
> a bus-dependent implementation), a list of resources assigned to the
> device and a reference to the driver attached (if any; newly written
> drivers will need no resource allocations themselves -- they just
> allocate the whole device).
Allocating the entire device strikes me as extremely limiting.
parport already needs to share the same parallel port, and the stuff I
am interested in -- VGA and video drivers -- often wind up needing to
share the VGA ports. In order to support multiple VGA cards in a single
machine, I do this
pci_disable_other_vga_card_io_regions()
pci_enable_my_vga_card_io_regions()
{ the fb driver does some VGA port I/O }
pci_disable_my_vga_card_io_regions()
pci_enable_other_vga_card_io_regions()
The resource manager below should IMHO solve the problem of
sub-allocation of a resource.
> Drivers
> ~~~~~~~
> Driver entry points and parameter passing should be unified -- no more
> differences between modules and drivers compiled in the kernel.
Woo hoo!
> Resource management
> ~~~~~~~~~~~~~~~~~~~
> We need a better resource manager which will not only prevent drivers
> from clashing with each other (today we do it for I/O only anyway), but
> also will be able to assign free address space regions to newly inserted
> cards. This includes keeping a list of assigned I/O addresses, memory
> blocks, IRQs and DMA channels.
This is definitely important, as one particular S3 card will report its
MMIO region as 32 MB instead of the correct 64 MB.
> Naming of devices
> ~~~~~~~~~~~~~~~~~
> Naming of devices is a hard issue and (as shown during recent talks at
> the linux-usb list) no solution is correct -- some of them are too complex
> for simple workstation, some fail on large servers with lots of devices
> being swapped in mysterious ways. Therefore it should be a matter of user
> choice and as such a userland issue.
2.3.x needs devfs badly, IMHO
> [time passes, water in the river flows and the user finally decides to unplug
> the device.]
>
> (4) The bus-dependent code receives an unplug notification and sends
> it to the driver. The driver releases the device, bus-dependent
> code removes it and deallocates all of its resources. Done.
This feature will be great for debugging drivers too, and (if I read
this correctly) maybe even make driver unloading more sane in general.
> PCI
> ~~~
> PCI can be adapted to this approach very easily and in a backward-compatible
> way. Outside of PCI subsystem implementation details, the drivers never need
> to know bus and device numbers -- they can just use the pci_dev structure
> as a opaque handle representing the device and pass it to generic PCI services
> if they want to read/write configuration registers (we already use this
> approach anyway).
Slightly off topic: What about AGP? Is any work or planning going on
in that direction? I know it's compatible with PCI, but there don't
seem to be any constants in the kernel yet for accessing the new
configuration commands and such.
> Device access
> ~~~~~~~~~~~~~
> All addresses in device nodes should be expressed as physical addresses,
> i.e. those accepted by ioremap(), /dev/mem and similar interfaces. Each bus
> should also define phys_to_bus and bus_to_phys translation functions, because
> address translating differs from bus to bus even on one architecture. Also
> a separate functions for requesting address translation before doing a DMA
> and freeing it after doing a DMA should be created to handle IOMMUs correctly.
>
> readb() and similar functions should no longer accept and automatically convert
> ISA addresses. Most drivers should be converted to use ioremap()
> properly and if it's too hard, isa_readb() introduced and used instead
> of readb() in non-converted drivers.
> readl() et al. should also exist in variants directly specifying endianity
> of target data.
This is also very valuable. The newer S3 cards (and others as well)
fully support big endian as well as little endian, and it would be nice
to avoid the byteswapping that occurs in some current read*()
implementations, such as on PPC (and Sparc too?).
Thanks for all your hard work Martin,
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/