> > It was just the first driver I got, so far only an example (bad one).
> > What about aha?
>
> It would be nice to be able te detach most drivers. I think that when aha
> was converted originally, cam didn't support detach but I'm pretty sure it
> does now.
The cam_sim_free hasn't been exerci
Thus spake Sergey Babkin ([EMAIL PROTECTED]):
> the old version somehow wedges the system. And upgrading drivers
> on a running production system is not something I personally would
> do. This is a dangerous operation and if it would cause any problems
Heh. Of course.
But also the bktr-driver,
On Sat, 20 May 2000, Alexander Langer wrote:
> Yes. But what about the others.
> /sys/dev/aha/aha_mca.c for example - it is part of module (aha),
> allocs resources, but never releases them.
Not on my system. You can't build a module that includes front ends for
busses that may not be loaded.
In message <[EMAIL PROTECTED]> Sergey Babkin writes:
: Well, I suppose unloading drivers makes much sense only in case
: if hardware supports hot-plug.
And when one is developing the driver, it helps a whole lot to add
unload capability. kldunload takes 1 second. reboot takes 120.
: I see the
In message <[EMAIL PROTECTED]> Alexander Langer writes:
: > compiled in the kernel (as opposed to being loaded as a module)
: > then it never gets unloaded. And many drivers were written before
: > the loadable modules appeared.
:
: Yes. But what about the others.
: /sys/dev/aha/aha_mca.c for ex
Alexander Langer wrote:
>
> Thus spake Sergey Babkin ([EMAIL PROTECTED]):
>
> > compiled in the kernel (as opposed to being loaded as a module)
> > then it never gets unloaded. And many drivers were written before
> > the loadable modules appeared.
>
> Yes. But what about the others.
> /sys/dev
On Sat, 20 May 2000, Alexander Langer wrote:
> Thus spake Doug Rabson ([EMAIL PROTECTED]):
>
> > There is really no need. The mcclock driver can't be detached since its
> > required for normal system functioning (its the main clock source).
>
> OK. I agree.
> It was just the first driver I got,
In message <[EMAIL PROTECTED]> Alexander Langer writes:
: > : Strange. Enlighten me, please. .-9
: > If you don't have a detach routine, you can't unload the driver.
:
: How does one unload aha.ko then (for the aha_mca.c cards)?
One doesn't unload aha right now.
: That needs to be fixed. Shall
Thus spake Doug Rabson ([EMAIL PROTECTED]):
> There is really no need. The mcclock driver can't be detached since its
> required for normal system functioning (its the main clock source).
OK. I agree.
It was just the first driver I got, so far only an example (bad one).
What about aha?
Alex
-
On Sat, 20 May 2000, Alexander Langer wrote:
> Hello!
>
> See sys/alpha/isa/mcclock_isa.c:
> It has attach (which allocs resource), but not detach.
> Also, it doesn't save the rid in the softc.
>
> I wonder, if the generic detach function is capable to clean up the
> resource without knowing th
Thus spake Warner Losh ([EMAIL PROTECTED]):
> : Strange. Enlighten me, please. .-9
> If you don't have a detach routine, you can't unload the driver.
How does one unload aha.ko then (for the aha_mca.c cards)?
That needs to be fixed. Shall I?
Alex
--
I need a new ~/.sig.
To Unsubscribe: sen
Thus spake Sergey Babkin ([EMAIL PROTECTED]):
> compiled in the kernel (as opposed to being loaded as a module)
> then it never gets unloaded. And many drivers were written before
> the loadable modules appeared.
Yes. But what about the others.
/sys/dev/aha/aha_mca.c for example - it is part of
In message <[EMAIL PROTECTED]> Alexander
Langer writes:
: Strange. Enlighten me, please. .-9
If you don't have a detach routine, you can't unload the driver.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Alexander Langer wrote:
>
> Thus spake Alexander Langer ([EMAIL PROTECTED]):
>
> > If so, I'm going to write patches.
>
> ... for almost every driver in the tree.
>
> Hmm. EITHER almost all people never unloaded their driver, or I still
> understood wide parts wrong.
>
> I grepped through /sy
Thus spake Alexander Langer ([EMAIL PROTECTED]):
> If so, I'm going to write patches.
... for almost every driver in the tree.
Hmm. EITHER almost all people never unloaded their driver, or I still
understood wide parts wrong.
I grepped through /sys now and only 10% of the drivers save the rid.
Hello!
See sys/alpha/isa/mcclock_isa.c:
It has attach (which allocs resource), but not detach.
Also, it doesn't save the rid in the softc.
I wonder, if the generic detach function is capable to clean up the
resource without knowing the rid, or if this is a bug.
If so, I'm going to write patches
16 matches
Mail list logo
