On Wed, Sep 23, 2015 at 9:26 AM, Warner Losh <[email protected]> wrote:
> Nearly all the PCI drivers have tables of vendor/device IDs. > They all have slightly different forms, and none of them use > a common macro / format like USB. So each driver needs a > line or two to describe the table so we can extract the data > from the .ko. Some drivers don't have lists, and those will > need to be dealt with on a case-by-case basis. > > I also have another set of work to do PNP translations at run > time. The bus will lie about the PNP IDs of the device so that > drivers can treat new hardware just like old hardware. The obvious > (and wrong) approach of forcing drivers to "take" devices only > works for the most trivial drivers as nearly all of them have a > table that tells about the "quirks" of the hardware since not > all of that can be determined from registers alone. > > Warner > > All over the world , almost all of the products have a "Bar Code" identifier , which approximately may be considered "Unique" . Is there a possibility to associate PCI and USB and other devices with their bar code identifiers ? For computers assembled already , it will be necessary to ask to sellers to supply bar codes of included devices . By using product bar codes , I think , it will be possible to identify uniquely a large number of devices . In that way , it will also be possible to define device characteristics correctly even they lie about their parameters . Mehmet Erol Sanliturk > On Tue, Sep 22, 2015 at 5:38 PM, Mehmet Erol Sanliturk < > [email protected]> wrote: > >> >> >> On Tue, Sep 22, 2015 at 2:38 PM, Warner Losh <[email protected]> wrote: >> >>> I need help with PCI driver marking. Grab my patches and we can talk. >>> >>> Basically, it marks all the .ko modules in a similar way that we do >>> inter-module >>> dependencies with plug and play info. kldxref then takes this data and >>> stuffs >>> it in loader.hints. I also need to write something that will parse this >>> data and >>> either generate a devd.conf file (easy to do from kldxref sources) or >>> queues >>> the load drive in the kernel (kinda hard). Bonus points for similar code >>> in >>> /boot/loader for any storage device that’s found. >>> >>> Warner >>> >>> >>> > On Sep 22, 2015, at 1:12 AM, Mehmet Erol Sanliturk < >>> [email protected]> wrote: >>> > >>> > >>> > >>> > On Mon, Sep 21, 2015 at 11:58 PM, Hans Petter Selasky <[email protected]> >>> wrote: >>> > On 09/22/15 00:58, Mehmet Erol Sanliturk wrote: >>> > On Mon, Sep 21, 2015 at 2:16 PM, Maxime Soulé<[email protected]> >>> > wrote: >>> > >>> > One of my wishes is to move ALL of the device definition information >>> for ( >>> > NIC , USB , and other devices ) into files where for each device ( a >>> unique >>> > file to dedicated itself containing information presently defined as >>> preset >>> > in internal arrays with one additional information ( at least ) which >>> > driver will be used for the device ) will be prepared . >>> > >>> > >>> > Hi Mehmet, >>> > >>> > Warner Losh is working on this currently, CC'ed. See: >>> > >>> > https://reviews.freebsd.org/D3458 >>> > >>> > Maybe you want to help out testing? >>> > >>> > --HPS >>> > >>> > >>> > >>> > If I can help in any way , I will do it . >>> > >>> > >>> > Mehmet Erol Sanliturk >>> > >>> > >>> >>> >> >> >> What does "PCI driver marking" mean ? >> >> >> Mehmet Erol Sanliturk >> >> >> >> > _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[email protected]"
