Date: Sat, 23 Aug 2008 00:47:53 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: ahornung@gmail.com Cc: freebsd-hackers@freebsd.org Subject: Re: Driver accessing other drivers/devices ? Message-ID: <20080823.004753.1477561239.imp@bsdimp.com> In-Reply-To: <10fba67b0808220034t2b9598cekbad7c976eed6975f@mail.gmail.com> References: <10fba67b0808220034t2b9598cekbad7c976eed6975f@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <10fba67b0808220034t2b9598cekbad7c976eed6975f@mail.gmail.com>
"Alex Hornung" <ahornung@gmail.com> writes:
: Hello,
:
: I need to access the hard disk from within a driver that is not a FS.
: I would also need to get a list of PCI devices connected. Is there a
: way I can access these devices directly, at least in the first case,
: issuing directly ATA/IDE commands to the hard disk?
There's always ata_if.m...
: In the case of PCI it would be even nicer to be able to communicate
: with the pci driver... but if that's not possible, it's also ok if I
: can access the PCI bus controller directly. The driver I'm writing is
: not a PCI or PCI device driver either.
:
: Hope someone can help me out on this one, it's important that there's
: no user-space code...
Generally, you don't want to scan the PCI bus to look for drivers to
talk to. That's bad kharma and likely begging to be abused.
Having said that, I've had cooperative drivers in the kernel before.
They usually look for each other and send messages to each other with
kobj. It is better to look for "friend0" that you know can receive
messages. kobj adds a layer of protection since it will gracefully
give an error when you can't do it.
Hey, wait, ata_if is kobj... You could likely expand it to allow
queueing of commands and such.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080823.004753.1477561239.imp>