Hardware compatibility list

Andriy said:
msplsh said:
There no hope of being able to generate vendor/device IDs tables automatically from drivers? With that, being able to index those into other databases would make questions like this somewhat answerable.
Click to expand...
It's doable, of course, but it's not trivial and it won't tell the whole story.
The same chip may work fine in one piece of hardware but not so much in another.
There can a same chip ID but a different revision with its own quirks.
Also, you may not know chip IDs of a piece of hardware until you actually get your hands on it, you would only know its marketing name.

In any case, the idea of an "official" support list for a volunteer project seems rather bogus.
It's not like there is an "official" test / certification team, "official" support team, "official" support contract, etc.
The community effort and database of hardware that people actually use is the best we can get (for free).

If anyone needs better, then they should go to vendors or system integrators, etc.
Click to expand...
I agree with your remarks Andriy including your caveats. However I think that such information* could make it (much) easier to find things like I219-LM not detected & re(4) versus net/realtek-re-kmod (see here) ; and keep in mind that there are probably more problems like those that we don't see on the forums.

Much of everything with FreeBSD has to do with wise management of limited resources. Writing (a lot) more drivers for new hardware is not feasible with current available resources. To make information available in a standard, searchable and extendable way about drivers that have allready been developed is feasible, I think.

What I can see as (mainly management and supervising) tasks are:
  1. db selection and db design suitable to hold the information
  2. inserting data and updating the db
FreeBSD does not produce drivers by the dozen each day so, after the initial insertion, new data won't be high volume. Even when there needs to be a separation between the FreeBSD source tree and the ports tree, the two db data structures should be able to merge and if not then you query them separately, as long as they can be queried in the same way. Such an initiave could even be supported by the FreeBSD Foundation.

Once there is a stable (db) structure that holds the information I'm sure that FreeBSD users will develop front ends if needed, be it text or GUI based.

___
* I have not looked at the source code but some kind of look-up-system must already be present in FreeBSD because during installation detected hardware is matched to a specific driver.
 
Maybe a good community exercise could be to analyse and discover *why* community lead hardware compatibility databases always become unmaintained and out of date. Then we can see if we can identify any solutions to protect against that.
 
Just to clarify and address your point: I do not have in mind a hardware compatibility list, at least to the extend some list where a network card, disk controller card etc. of vendor X, Y or Z is entered and is deemed "FreeBSD qualified". I know, this is what the OP and many more are looking for when you want to make hardware selections, especially before buying.

I'd like to know if such centralised information would be easily feasible; useful and easy to maintain; holding the information that is already present in the source code (and man pages) of drivers in the base install and ports.

If the consensus is, based on experience, is that this would become unmaintainable and can't be mitigated or controlled, then, I (sadly) give way to the ones that have much more experience than I have in such matters.
 
Andriy said:
The community effort and database of hardware that people actually use is the best we can get (for free).
Click to expand...
I understand all your caveats, but I think if the community effort could start from a place of "these are the IDs that drivers X will at least attempt to work with" then they could fill in the blanks with "Ok, but not this one" etc.
 
Andriy said:
… the idea of an "official" support list for a volunteer project seems rather bogus.
Click to expand...

Perhaps, although a list published at the official website is implicitly official.

It's not like there is an "official" test / certification team, "official" support team, "official" support contract, etc.
The community effort and database of hardware that people actually use is the best we can get (for free).
Click to expand...

I imagine that the hardware test lab is official.

… to vendors or system integrators, etc.
Click to expand...

FreeBSD bug {link removed}
 
Last edited:
One could create a list that says "USB vendor 0x0baf product 0x0303 is recognized by a driver, so it has at least a chance of working". That is fundamentally what msplsh proposed above. But for people who are trying to buy a product this is de-facto useless, since by the time they can read these numbers, they have the device in their hand, and can actually test it. And furthermore, as Andriy said above, the above information is sometimes correct, sometimes incorrect. Exactly the same goes for PCI hardware: Telling people (like jrm grahamperrin did above) that "LSI 95xx chips are supported but 9600 are not" does not help. They are looking for a different layer, namely "Buy a Dell 1234 or a HP 5678 card and it will work".

Until hardware vendors start doing support for FreeBSD themselves, the best we can get out of a FreeBSD-sponsored hardware testing lab is a short list, of older hardware. The FreeBSD foundation's budget is not sufficient for a massive hardware testing lab (there are literally thousands of graphics, network and storage cards that need to be tested, and tens of thousands of USB devices).

EDIT: Sorry, mis-identified the poster above. And I'm not disagreeing with jrm.
 
You must log in or register to reply here.
Back
Top