Date: Fri, 22 Aug 2008 14:13:12 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: rizzo@iet.unipi.it Cc: brooks@FreeBSD.org, ivoras@FreeBSD.org, brueffer@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Magic symlinks redux Message-ID: <20080822.141312.732640662.imp@bsdimp.com> In-Reply-To: <20080822193657.GB63527@onelab2.iet.unipi.it> References: <20080822162259.GA61694@onelab2.iet.unipi.it> <20080822.124019.-692152321.imp@bsdimp.com> <20080822193657.GB63527@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20080822193657.GB63527@onelab2.iet.unipi.it>
Luigi Rizzo <rizzo@iet.unipi.it> writes:
: On Fri, Aug 22, 2008 at 12:40:19PM -0600, M. Warner Losh wrote:
: > In message: <20080822162259.GA61694@onelab2.iet.unipi.it>
: > Luigi Rizzo <rizzo@iet.unipi.it> writes:
: > : Also, we do have a need to push tables of info in the kernel
: > : (e.g. list of PCI/USB ids, quirks tables and the like),
: > : maybe we can take this chance to make the varsym subsystem useful
: > : also within device drivers ?
: >
: > No. what problem would this solve?
:
: take e.g. uscanner (or several other devices, e.g. if_rl)
: where the only way to tell whether a device
: is supported or not is looking up a table of usb vendor/id
: (the same happens for many pci devices). in the simple cases
: you just need the id - a more complex one would use
How is this related? I guess was my question.
Also, this problem isn't just replacing a table in the kernel. The
problem is "map this ID to that ID" because many drivers do special
things for different IDs, and you have to specify the ID that it is
compatible with.
: linux has a way (forget what the command name is) to add entries
: to the table at runtime, whereas on freebsd
: we need to patch&rebuild the module.
:
: if make this 'object store' thing (varsym) able to store arrays we
: could have device drivers scan the arrays (e.g. uscanner_id or
: if_rl_pciids etc.) to find out if it has a suitable string.
That's the wrong way to solve the problem. In FreeBSD there's no
universal table on any bus except for PC Card. Until we have that,
this solution can't happen. Each driver has its own ad-hoc way of
doing this. Even in PC Card land, the size of the table isn't
exported.
The way that drivers are written today in FreeBSD, the bus has to
provide this translation layer. There's really no other viable
solution. If someone goes through and fixes all the important busses,
then maybe this would be a needed service.
: one objection that is frequently raised is that randomly adding ids
: to a kernel table is a potential source of panics, but in the end,
: to do this you need root access so you could as well rm -rf / and
: make a similar if not worse damage.
Panic! Well, I'm sold.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080822.141312.732640662.imp>