Date: Mon, 13 Nov 2000 00:43:10 -0800 From: Mike Smith <msmith@freebsd.org> To: Robert Lipe <robertlipe@usa.net> Cc: freebsd-hackers@freebsd.org Subject: Re: pci bus enumeration & cdevsw indexing Message-ID: <200011130843.eAD8hAF01093@mass.osd.bsdi.com> In-Reply-To: Your message of "Mon, 13 Nov 2000 00:44:10 CST." <20001113004410.W20018@rjlhome.sco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I'm new to FreeBSD, but an experienced kernel guy. I'm workgin with
> 4.1.1 on IA32 and need help understanding the ways of your world. :-)
> I'd like my project to look like a "normal" driver and use supported
> interfaces, but I'll patch the core code if I need to.
This willingness is good. 8)
> I have a need to walk the PCI bus, gleaning PCI IDs and other data.
> (Yes, I know a dozen reasons why to NOT do that.) What I *almost*
> need is the loop in pci_ioctl that walks pci_dev[]. The catch here is
> that this is a private data structure (static, lots of dependencies on
> private headers not in <sys/...>, etc) and therefore unavailable. I
> considered calling the ioctl code myself from withing my driver, but
> that seems too weird. I thought about shipping the data to myself by
> way of user-space (daemon does an ioctl ('pciconf -l'ish) to PCI driver,
> turns around and hands data to me on an ioctl) but that sounds like an
> application to be punished.
It's definitely not the "right" way to do things. As Ken asked - why are
you doing things this way? Are the devices you're interested in likely
to be attached to by drivers of their own? Is your driver always going
to be in the kernel, or is it liable to be loaded as a module?
> Is there a "normal" way for a conforming driver to walk the busses,
> pluck out bus number, slot number, device id, subsystem id, and all that
> traditional stuff, or do I just need to carve up pci.c and build my own
> interface to do it?
There isn't a "normal" way for this, because in our view of the world
that's the wrong way to do it. (Whether that's absolutely right is
entirely open to debate, of course.) In most cases, you can achieve the
same thing using other techniques.
> Also, I have a question on loadable character devices. Is there a way
> to avoid the hard-coded major numbers in the cdevsw[] entry that's
> passed? It seems like make_dev() should be able to roam cdevsw, find
> an empty slot, and create the dev nodes for me. I'm envisioning a very
> dynamic system with lots of modules (enough that we really don't want to
> allocate them with a human involved) being popped in and out and would
> like to not handle the major number management and inevitable conflicts
> on my own.
This is what devfs is meant to achieve. Unfortunately at the moment the
major numbers need to be fixed because there's no dynamism in /dev. If
you don't need the /dev nodes, then of course you don't need major
numbers at all...
> How is this handled for, say, third-party drivers?
Typically in the past we've just handed out major numbers to vendors
wanting to ship public drivers, or for in-house stuff just advocated using
the "local" ranges.
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011130843.eAD8hAF01093>