Re: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load of USB kernel modules]
2011/6/26 Warner Losh i...@bsdimp.com: I like the idea of having a standardized table. I've done this with PC Card and it really works well. It isn't the design pattern that all drivers use, and it may be hard to get everyone lined up on this. I tried PCI back after I did PC Card and met resistance. Most of the resistance was from people that are no longer active in the project, so I think that we could do this today. I suspect that some of the vendor drivers today might stand in the way of having PCI be completely uniform. The big advantage of USB is that it is uniform now. PCI isn't. It would take a lot of work to make it uniform. If only some PCI drivers can be made uniform, why not provide devd autoload support only to those drivers whose maintainers choose to make them uniform? This would give those opposing uniformity a compelling reason to change their view, without forcing them into it. -- Robert Millan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load of USB kernel modules]
On Jul 15, 2011, at 9:03 AM, Robert Millan wrote: 2011/6/26 Warner Losh i...@bsdimp.com: I like the idea of having a standardized table. I've done this with PC Card and it really works well. It isn't the design pattern that all drivers use, and it may be hard to get everyone lined up on this. I tried PCI back after I did PC Card and met resistance. Most of the resistance was from people that are no longer active in the project, so I think that we could do this today. I suspect that some of the vendor drivers today might stand in the way of having PCI be completely uniform. The big advantage of USB is that it is uniform now. PCI isn't. It would take a lot of work to make it uniform. If only some PCI drivers can be made uniform, why not provide devd autoload support only to those drivers whose maintainers choose to make them uniform? This would give those opposing uniformity a compelling reason to change their view, without forcing them into it. Sure. The problem is that I don't want it to be another hack like the current USB which is specific to PCI. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load of USB kernel modules]
On Jun 25, 2011, at 11:38 PM, Hans Petter Selasky wrote:
On Saturday 25 June 2011 19:07:01 Hans Petter Selasky wrote:
On Saturday 25 June 2011 18:45:14 Warner Losh wrote:
On Jun 25, 2011, at 9:42 AM, Hans Petter Selasky wrote:
On Saturday 25 June 2011 01:05:26 Jeremy Messenger wrote:
Jeremy Messenger
Done.
http://svn.freebsd.org/changeset/base/223536
Please move it back. It doesn't belong in /etc/defaults. It belongs in
/etc/devd if we're going to have it at all. If you have a full GENERIC
kernel, there will never be a NOMATCH line generated, so these entries
will just be ignored.
Warner
Done.
http://svn.freebsd.org/changeset/base/223543
Hi,
I see that a lot of PCI device drivers use code to check their ID's.
One simple way to dump all the PCI device ID's is to compile or load all
modules and then make a dummy PCI device, which only calls device_probe on
the
full 32-bit space of the pci_get_devid(). This should take in matter of some
minutes to produce a complete list of PCI ID's. Then add these ID's to all
the
respective drivers like a generic device ID table:
struct pci_device_id {
uint32_t device_id;
uint32_t card_id;
const char *description;
unsigned long driver_info;
} __aligned(32);
Then export those automatically generated structures into the pci_device_id
section and have tools/bus_autoconf generate the matching rules.
PCI format structure for bus_autoconf:
pci_device_id{256,:}
device_id[0]{ U32_XOR ,8}
device_id[1]{ U32_XOR ,8}
device_id[2]{ U32_XOR ,8}
device_id[3]{ U32_XOR ,8}
card_id[0]{ U32_XOR ,8}
card_id[1]{ U32_XOR ,8}
card_id[2]{ U32_XOR ,8}
card_id[3]{ U32_XOR ,8}
I like the idea of having a standardized table. I've done this with PC Card
and it really works well. It isn't the design pattern that all drivers use,
and it may be hard to get everyone lined up on this. I tried PCI back after I
did PC Card and met resistance. Most of the resistance was from people that
are no longer active in the project, so I think that we could do this today.
I suspect that some of the vendor drivers today might stand in the way of
having PCI be completely uniform.
The big advantage of USB is that it is uniform now. PCI isn't. It would take
a lot of work to make it uniform.
Also, like I was saying on IRC, I don't like the fact that we have to have
different bus code in this automatic tool. It shouldn't know nor care about
what the bus or drivers do. The drivers should export a table and a descriptor
for the table that would allow it to either generate the devd.conf lines needed
to do the matching, or for some other program to examine the pnp_string
information from newbus and figure out which module(s) to load. Also, I don't
find the above syntax easy to read or understand (sorry).
Don't get me wrong. I love the USB autoload code you've done so far, but I
consider it more of a prototype for the final system than the final system
itself.
Warner___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load of USB kernel modules]
2011/6/26 Hans Petter Selasky hsela...@c2i.net: Hi, I see that a lot of PCI device drivers use code to check their ID's. [...] I seem to recall devd doesn't process PCI because it is event-driven and there are no events associated with PCI cards. Perhaps it could be modified to scan for PCI cards via libpci on initialization and generate fake events for them? -- Robert Millan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load of USB kernel modules]
On Jun 26, 2011, at 4:33 AM, Robert Millan wrote: 2011/6/26 Hans Petter Selasky hsela...@c2i.net: Hi, I see that a lot of PCI device drivers use code to check their ID's. [...] I seem to recall devd doesn't process PCI because it is event-driven and there are no events associated with PCI cards. That's totally false. Perhaps it could be modified to scan for PCI cards via libpci on initialization and generate fake events for them? Since your premise is false, this solution also is false. Devices are handled in a completely uniform manner in the system. When they attach, an attach even is generated. When they detach, a detach event is generated. When there is no driver attached after the probe/attach sequence, a NOMATCH event is generated. Events are queued up during the early boot process until devd can run. They are then processed in order. Devices that haven't had a driver attach to them would be processed when devd had a chance to start. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load of USB kernel modules]
On Saturday 25 June 2011 19:07:01 Hans Petter Selasky wrote:
On Saturday 25 June 2011 18:45:14 Warner Losh wrote:
On Jun 25, 2011, at 9:42 AM, Hans Petter Selasky wrote:
On Saturday 25 June 2011 01:05:26 Jeremy Messenger wrote:
Jeremy Messenger
Done.
http://svn.freebsd.org/changeset/base/223536
Please move it back. It doesn't belong in /etc/defaults. It belongs in
/etc/devd if we're going to have it at all. If you have a full GENERIC
kernel, there will never be a NOMATCH line generated, so these entries
will just be ignored.
Warner
Done.
http://svn.freebsd.org/changeset/base/223543
Hi,
I see that a lot of PCI device drivers use code to check their ID's.
One simple way to dump all the PCI device ID's is to compile or load all
modules and then make a dummy PCI device, which only calls device_probe on the
full 32-bit space of the pci_get_devid(). This should take in matter of some
minutes to produce a complete list of PCI ID's. Then add these ID's to all the
respective drivers like a generic device ID table:
struct pci_device_id {
uint32_t device_id;
uint32_t card_id;
const char *description;
unsigned long driver_info;
} __aligned(32);
Then export those automatically generated structures into the pci_device_id
section and have tools/bus_autoconf generate the matching rules.
PCI format structure for bus_autoconf:
pci_device_id{256,:}
device_id[0]{ U32_XOR ,8}
device_id[1]{ U32_XOR ,8}
device_id[2]{ U32_XOR ,8}
device_id[3]{ U32_XOR ,8}
card_id[0]{ U32_XOR ,8}
card_id[1]{ U32_XOR ,8}
card_id[2]{ U32_XOR ,8}
card_id[3]{ U32_XOR ,8}
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
