Messages in this thread | | | Subject | Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access | From | Krzysztof Halasa <> | Date | Mon, 08 May 2006 02:03:34 +0200 |
| |
Kyle Moffett <mrmacman_g4@mac.com> writes:
> 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.
Look, it's me who's using that and I tell you I want just that :-)
> Ewww, I certainly wouldn't trust a binary statically-linked binary > program that mmaps /dev/mem or /dev/kmem
And would you trust a binary which doesn't have "/dev/mem" string in it?
Anyway you can compile it yourself if you want. It's not about trust, it's about simplicity and robustness.
> #! /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!
Sure. If the driver is loaded/available. What if, say, the distribution you use doesn't have it?
> 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.
So what? The driver and EEPROM updater don't conflict.
> If you want to add firmware > update capability, add it to the preexisting primary driver.
It will not load with blank or invalid EEPROM :-)
> No, not an "enable" interface. In this case the kernel should do > basically all of the poking at PCI resources for you.
Because?
> 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.
It has nothing to do with any "ROM". -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |