Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access

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

 



On May 7, 2006, at 08:05:59, Krzysztof Halasa wrote:
Kyle Moffett <[email protected]> writes:
Jon Smirl gave a great description of exactly how to write such a "driver". I seem to recall that we already have the ability to trigger manual PCI binding by bus:slot number; in combination with an appropriate "write EEPROM with firmware file" driver that has no default list of PCI devices; you could easily manually trigger a bind of the device.

Writing EEPROM is not a problem and can be done safely from user space (mmap /dev/mem).

This is *exactly* what we don't want to do! The whole point of this thread is to prevent the need to use /dev/mem and /dev/kmem for anything except debugging.

Doing it in the kernel seems like an overkill, especially if you do the operation once in few years it's much easier to just download a (statically linked?) binary than messing with the kernel.

Ewww, I certainly wouldn't trust a binary statically-linked binary program that mmaps /dev/mem or /dev/kmem, and I certainly bet that 90% of the people on this list would feel likewise. We'd much prefer a program which does this:

  #! /bin/sh
  cp firmware.bin /lib/firmware/some_firmware_file.bin
  echo -n eeprom_load_driver >/sys/device/$PCI_ID/bind
  echo -n 1 >/sys/device/$PCI_ID/unbind

Simple, obviously correct, and uses a nice reuseable driver too!

It doesn't even interfere with the "main" driver and can be done while the device is operating (given that previous EEPROM made sense, otherwise the driver would not load).

No! That would be even worse! You're then having userspace poke at the driver while a kernel driver is loaded, which is *exactly* what X is getting into trouble for doing. If you want to add firmware update capability, add it to the preexisting primary driver.

In any case what you really need for all those cases is a simplistic stub driver that provides some sort of in-kernel mutual exclusion.

Right. I.e., "enable" interface with, possibly, locking mechanism, instead of some per-class "driver".

No, not an "enable" interface. In this case the kernel should do basically all of the poking at PCI resources for you. If you _really_ want to do that kind of update in userspace, write a stub driver which just enables the device on bind, disables it on unbind, and mmap and write to the sysfs "rom" file.

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux