Re: newbus flaw
From: Doug Rabson (dfr_at_nlsystems.com)
Date: 05/13/04
- Previous message: Dag-Erling Smørgrav: "Re: newbus flaw"
- In reply to: Dag-Erling Smørgrav: "Re: newbus flaw"
- Next in thread: M. Warner Losh: "Re: newbus flaw"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: Dag-Erling Smørgrav <des@des.no> Date: Thu, 13 May 2004 13:34:32 +0100
On Thu, 2004-05-13 at 11:46, Dag-Erling Smørgrav wrote:
> Doug Rabson <dfr@nlsystems.com> writes:
> > When the old module unloaded, its driver will have detached from the
> > device which it created. There is no reference to an old driver_t. Its
> > perfectly safe for the new driver to use the old device.
>
> so why do you say I "shouldn't reset the old driver and desc"?
I didn't say that (that was John-Mark). When you create a device using
something like device_add_child(parent, "foo", unit), the new device is
just labelled as a 'fooN' - it has no reference to any 'foo' driver and
should have since there may be several. The 'foo'ness of the device is
used to match the device against a suitable driver at probe time.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Dag-Erling Smørgrav: "Re: newbus flaw"
- In reply to: Dag-Erling Smørgrav: "Re: newbus flaw"
- Next in thread: M. Warner Losh: "Re: newbus flaw"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: distributed module configuration
... tristate "do you want foo?" ... by reducing a driver with one file. ...
Agreed - simple drivers would then be a single file - and thats a good argument. ... (and
sometime in the Makefile there are some wrong hacks). ... (Linux-Kernel) - [RFC] Pushing device/driver binding decisions to userspace
... Driver foo supports devices a, ... So this then becomes a decision that the
kernel cannot make. ... So my ultimate goal is to somehow move this decision making to
udev. ... (Linux-Kernel) - Re: [RFC] Pushing device/driver binding decisions to userspace
... Driver foo supports devices a, ... So this then becomes a decision that the
kernel cannot make. ... So my ultimate goal is to somehow move this decision making to
udev. ... (Linux-Kernel) - Re: Can we link a windows driver (.sys) with our own code ?...
... If you want to intercept calls to the kernel, ... driver and then
modify the call/pass it on/reject/block the call. ... if a driver invokes a function foo()
provided by the windows ... (microsoft.public.development.device.drivers) - Re: Can we link a windows driver (.sys) with our own code ?...
... Basically you cannot directly call kernel code, including your driver, from
... > Once a function call is intercepted, we can do some preprocessing jobs, ...
if a driver invokes a function foo() provided by the windows ... (microsoft.public.development.device.drivers)