> >
> > I built a kernel without 'device miibus' and 'device xl' and it
> > automatically loaded the drivers when I manually did 'ifconfig'. But
> > it didn't load them from rc.conf, where I have my ethernet card
> > configured like so:
> >
> > ifconfig_xl0="inet 216.231.50.6 netmask 255.255
Cyrille Lefevre <[EMAIL PROTECTED]> writes:
> > Joseph Wright wrote:
> >
> > On Sun, Jun 18, 2000 at 04:14:51AM +0200, Cyrille Lefevre wrote:
> > > "Daniel C. Sobral" <[EMAIL PROTECTED]> writes:
> > >
> > > > > Joseph Wright wrote:
> > > > >
> > > > > Since when? Any that I've ever needed had
> Joseph Wright wrote:
>
> On Sun, Jun 18, 2000 at 04:14:51AM +0200, Cyrille Lefevre wrote:
> > "Daniel C. Sobral" <[EMAIL PROTECTED]> writes:
> >
> > > > Joseph Wright wrote:
> > > >
> > > > Since when? Any that I've ever needed had to be compiled into the
> > > > kernel.
> > >
> > > Since w
In message <[EMAIL PROTECTED]> Peter Wemm writes:
: There is? There is a well-known leak for preload stuff - the pages
: are not (yet) reclaimed after unload. We have the infrastructure to
: do that now. See vm_page_t vm_add_new_page(vm_offset_t pa);
: This can be used to reclaim the space cons
Warner Losh wrote:
> Sure, there's a monster bug in the kldload/unload right now where that
> eats wired memory. That bug should be fixed.
There is? There is a well-known leak for preload stuff - the pages
are not (yet) reclaimed after unload. We have the infrastructure to
do that now. See
I'm only going to reply once to this thread
In message <[EMAIL PROTECTED]> Robert
Watson writes:
: And in a sense, we already have two kerneld's -- pccardd and usbd, which
: maintain mappings between named devices and drivers, etc. Combining them,
: and adding another source of requests (and LP
> > > > Not to mention "how much memory do you really gain by unloading modules"?
> > > > Considering the price of RAM these days (although not as low as
> > > > it was, but I won't be spending $650 US for 16M any time soon
> > > > again), the few K that unloading a bunch of modules saves won't
> > > Not to mention "how much memory do you really gain by unloading modules"?
> > > Considering the price of RAM these days (although not as low as
> > > it was, but I won't be spending $650 US for 16M any time soon
> > > again), the few K that unloading a bunch of modules saves won't
> > > E
Mike Smith wrote:
> >
> > The issue is with really small ram embedded systems.
> > Making things CAPABLE of being small is different from making
> > them dynamicly loadable.
>
> Nobody in their right mind is going to produce a "really small ram"
> embedded system that features the sort of nondete
I personally, don't see the reason for having this sort of thing in embedded
devices, either, a lot of which have just exactly what they need to operate in
the kernel, leaving nothing to be loaded or unloaded. As far as the kerneld
stuff goes, the kernel obviously provides us with an interface wit
> Mike Nowlin wrote:
> >
>
> > Not to mention "how much memory do you really gain by unloading modules"?
> > Considering the price of RAM these days (although not as low as
> > it was, but I won't be spending $650 US for 16M any time soon
> > again), the few K that unloading a bunch of modules
Mike Nowlin wrote:
>
> Not to mention "how much memory do you really gain by unloading modules"?
> Considering the price of RAM these days (although not as low as
> it was, but I won't be spending $650 US for 16M any time soon
> again), the few K that unloading a bunch of modules saves won't
> I personally consider leaving the kernel module loadable intact after
> boot to be a huge, huge security hole. Loadable modules... fine, but
> once the machine goes multi-user I want to up the securelevel and
> that disables any further kld operations. If one of the biggest
>
Yeah, I actually wasn't aware of the net and fs stuff at first. It works great
though, I was just continuing from what someone else had mentioned, and then it
got turned into kerneld for freebsd. I originally simply wanted to see about
options sort of like kerneld. I mean, maybe a utility
> On Wed, Jun 07, 2000 at 01:01:41AM -0400, Bosko Milekic wrote:
> >
> > An Operating System should only do that when the administrator is so
> > stupid that he/she actually loads "unused" drivers.
>
> I'm talking about for example a tape driver that was loaded to deal with
> a tape drive
On Wed, Jun 07, 2000 at 01:01:41AM -0400, Bosko Milekic wrote:
>
> An Operating System should only do that when the administrator is so
> stupid that he/she actually loads "unused" drivers.
I'm talking about for example a tape driver that was loaded to deal with
a tape drive which is cur
well, i've heard both negative and positive replies.
so, i've just open ``kerneld'' project on sourceforge.net
anyone who is interested, please, make your suggestions and wishes.
just drop me an e-mail at [EMAIL PROTECTED]
i'll be more than happy to hear from you. i'll try put working prototype on
Robert Watson wrote:
>
> I tend to agree, on face value, with an intuitive objection to kerneld.
> That said, it should be observed that a "kerneld" would restrict the code
> sufficiently privileged to cause a module load in one binary, as opposed
> to a model where that type of privilege has to
Coleman Kane wrote:
>
> I really don't think that stupidity is the issue, there are plenty of
> devices which you use very discretely which may only need support every
> once in awhile.
> It might be nice to start running on modules regularly. It would also be
> useful to be able to update your
> I personally consider leaving the kernel module loadable intact after
> boot to be a huge, huge security hole. Loadable modules... fine, but
> once the machine goes multi-user I want to up the securelevel and
> that disables any further kld operations.
This is great for your mu
On Wed 2000-06-07 (08:48), Coleman Kane wrote:
> Well, a lot of drivers aren't modules yet. It was basically an idea to
> move the kernel more towards a modular implementation. There will be a
> large number of modules if all the drivers were to become modules. It
> may not be, say, to everyone's
Well, a lot of drivers aren't modules yet. It was basically an idea to move the
kernel more towards a modular implementation. There will be a large number of
modules if all the drivers were to become modules. It may not be, say, to
everyone's liking to manually load a good deal of those. Plus, the
On Wed, 7 Jun 2000, Matthew Dillon wrote:
> I personally consider leaving the kernel module loadable intact after
> boot to be a huge, huge security hole. Loadable modules... fine, but
> once the machine goes multi-user I want to up the securelevel and
> that disables any further
On Wed 2000-06-07 (01:43), Coleman Kane wrote:
> I really don't think that stupidity is the issue, there are plenty of
> devices which you use very discretely which may only need support
> every once in awhile.
Once again, I don't think you're giving me enough clues as to what
you're aiming at.
I personally consider leaving the kernel module loadable intact after
boot to be a huge, huge security hole. Loadable modules... fine, but
once the machine goes multi-user I want to up the securelevel and
that disables any further kld operations. If one of the biggest
advant
On Mon, Jun 05, 2000 at 04:51:28PM -0700, Mike Smith wrote:
[...]
> TBH, unloading an idle module is basically a waste of time. Modules are,
> on the whole, so small that the savings are entirely outweighed by the
> unnecessary complexity.
What is won by unloading a module anyway? Memory the m
I really don't think that stupidity is the issue, there are plenty of devices
which you use very discretely which may only need support every once in awhile.
It might be nice to start running on modules regularly. It would also be useful
to be able to update your device driver while running freebs
+[ Bosko Milekic ]-
|
|
| An Operating System should only do that when the administrator is so
| stupid that he/she actually loads "unused" drivers.
As opposed to say it demand loading a driver for a File System type and
then unloading it w
On Wed, 7 Jun 2000, void wrote:
> Doesn't Solaris auto-unload unused drivers when memory gets tight?
>
> --
> Ben
>
> 220 go.ahead.make.my.day ESMTP Postfix
An Operating System should only do that when the administrator is so
stupid that he/she actually loads "unused" drivers.
--
On Tue, Jun 06, 2000 at 04:08:42PM -0700, Kris Kennaway wrote:
>
> You weren't listening..no-one debates the utility of auto-loading modules,
> and that is the direction FreeBSD is already heading. The debate is over
> the utility of automatically UNLOADING modules when they're "no longer in
> us
On Tue, 6 Jun 2000, Yevmenkin, Maksim N, CSCIO wrote:
> > No. Modules shouldn't be unloaded automatically.
^^
> but why? :-) what is wrong with that? it would be so nice to have small
> GENERIC kernel and bunch of modules. kernel will start, identify all
> hardwar
Yeah, it would be especially useful for the installation boot disks as well, to
have the ability to make a tiny kernel and load the appropriate device drivers.
Perhaps a database of some sort that keeps track of device IDs for various
drivers, to be able to auto load them. That's one example.
Ran
[...]
> > > This is, IMO, a good idea. I certainly don't want some
> > > smartass daemon
> > > unloading a module just because it thinks it should. 8)
> >
> > another option in config file? something like ``do_not_unload''?
>
> No. Modules shouldn't be unloaded automatically.
but why? :-)
Sorry, been working a strange schedule this week. By resources, I meant kernel
resources such as kmem space, from what I have been hearing though, it seems as
though the kernel does a lot this stuff already. I dunno, but someone else
posted awhile back about this, so I was still interested.
Mike
No, they are technically shareable, as long as you don't attept to
expect either of them at the software level to respond at a certain
time. This is why you can have COM2 and COM4 on the same interrupt in
windows or DOS, as long as you don't use them at the same time. The ISA
bus is a very simple
On Mon, 5 Jun 2000, Yevmenkin, Maksim N, CSCIO wrote:
> > I have no faith at all any metric other than one determined
> > by the module
> > itself to indicate "unuse", and if a module wants to unload
> > itself due to
>
> so you point is that we could put a "use/unuse" logic inside
> each o
Mike Smith wrote:
>
> > > and if a module wants to unload itself due to
> > > "unuse", it can already do so.
> >
> > You wouldn't have control over that process if the modules decides
> > for itself. It's a sysadmin decision to unload modules, not the
> > module's decision.
>
> So why introduce
> * Mike Smith <[EMAIL PROTECTED]> [000605 16:58] wrote:
> >
> > > Well, it would be nice to auto-load or unload any module that is needed.
> > > not just ethernet and fs types. That's basically the idea. Say, if you
> > > load a driver that uses some resources that another one can use while the
* Mike Smith <[EMAIL PROTECTED]> [000605 16:58] wrote:
>
> > Well, it would be nice to auto-load or unload any module that is needed.
> > not just ethernet and fs types. That's basically the idea. Say, if you
> > load a driver that uses some resources that another one can use while the
> > first
* Coleman Kane <[EMAIL PROTECTED]> [000605 16:19] wrote:
> Well, it would be nice to auto-load or unload any module that is
> needed. not just ethernet and fs types. That's basically the
> idea. Say, if you load a driver that uses some resources that
> another one can use while the first one is of
> Well, it would be nice to auto-load or unload any module that is needed.
> not just ethernet and fs types. That's basically the idea. Say, if you
> load a driver that uses some resources that another one can use while the
> first one is off... that's what I'm talking about.
"Some resources?"
> > and if a module wants to unload itself due to
> > "unuse", it can already do so.
>
> You wouldn't have control over that process if the modules decides
> for itself. It's a sysadmin decision to unload modules, not the
> module's decision.
So why introduce a third party? ("kerneld") If th
Well, it would be nice to auto-load or unload any module that is needed. not
just ethernet and fs types. That's basically the idea. Say, if you load a driver
that uses some resources that another one can use while the first one is off...
that's what I'm talking about.
Neil Blakey-Milner had the a
Mike Smith wrote:
>
> > Mike Smith wrote:
> > [...]
> > > This is, IMO, a good idea. I certainly don't want some smartass daemon
> > > unloading a module just because it thinks it should. 8)
> >
> > You can always patch kldunload and have cron periodically execute a
> > kldunload --unused-modu
> > Mike Smith wrote:
> > [...]
> > > This is, IMO, a good idea. I certainly don't want some
> smartass daemon
> > > unloading a module just because it thinks it should. 8)
[...]
> I have no faith at all any metric other than one determined
> by the module
> itself to indicate "unuse", and i
> Mike Smith wrote:
> [...]
> > This is, IMO, a good idea. I certainly don't want some smartass daemon
> > unloading a module just because it thinks it should. 8)
>
> You can always patch kldunload and have cron periodically execute a
> kldunload --unused-modules
> Or?
I have no faith at all
Mike Smith wrote:
[...]
> This is, IMO, a good idea. I certainly don't want some smartass daemon
> unloading a module just because it thinks it should. 8)
You can always patch kldunload and have cron periodically execute a
kldunload --unused-modules
Or?
Cheers,
Jeroen
--
Jeroen C. van Gelder
sorry, hit wrong key... :)
in addition to my previous message...
> > 2) kernel/user space does not unload modules, unless you
> > unload it manually
>
> This is, IMO, a good idea. I certainly don't want some
> smartass daemon
> unloading a module just because it thinks it should. 8)
anothe
[...]
> > 1) right now we have several places in kernel/user space where we
> > load KLD. if we need add dynamic module loading in some new
> > place we will have to duplicate all code
>
> This isn't necessarily bad, as it is this code which determines the
> criteria for loading a module. I'
> > On Sun 2000-06-04 (23:06), Coleman Kane wrote:
> > > Look through /modules...
> >
> > I'm still having problems working out what this will do. Can you
> > explain the differences between the current way of doing things, and
> > what your stuff will conceptually do?
> >
>
> i will try :-) p
> On Sun 2000-06-04 (23:06), Coleman Kane wrote:
> > Look through /modules...
>
> I'm still having problems working out what this will do. Can you
> explain the differences between the current way of doing things, and
> what your stuff will conceptually do?
>
i will try :-) please do not beat
i can see some interest, that is good :)
the working prototype can be found at
http://home.earthlink.net/~evmax/kerneld.tar.gz
so far it can dynamicly load
1) char devices (by major or both major and minor)
2) filesystems (by name). please note that ``mount_xxx''
utilities will load appropriate
On Sun 2000-06-04 (23:06), Coleman Kane wrote:
> Look through /modules...
I'm still having problems working out what this will do. Can you
explain the differences between the current way of doing things, and
what your stuff will conceptually do?
Neil
--
Neil Blakey-Milner
Sunesi Clinical Syste
On Sunday, June 04, 2000, Alfred Perlstein wrote:
> I thought Linux did away with thier kerneld concept. Afaik we can
> currently load a kld from within kernel context, can you please
> explain further what you want to do?
We can, and we also dynamically load modules when needed
(ifconfig,
Look through /modules...
Daniel C. Sobral had the audacity to say:
>
> M... ethernet drivers are already auto-loaded, fs modules are
> already auto-loaded... what am I missing?
>
> --
> Daniel C. Sobral (8-DCS)
>
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTEC
Coleman Kane wrote:
>
> Well, they are already moving in that direction with the newbus driver
> interface. It really simplifies converting your driver to a kld if
> you write it properly. Now a perfect addition would be a daemon or
> something that takes care of loading/unloading all of them so
On Sun, Jun 04, 2000 at 02:03:56PM -0400, Bob K wrote:
> If I understand what he's proposing correctly, he wants to develop a
> system in which all of the device drivers are loaded in the same way KLD's
> are.
>
> (I'm not a programmer, so I'd be unable to help)
Uhm. 90% of the klds _are_ devic
> > Would the person or person(s) interested in developing a kerneld-like, dynamic
> > module (un)loader for FreeBSD please email me. I am really interested in this.
> > It would be very advantageous to begin to move kld module use into the
> > mainstream for all components. I'd like to do what I
Well, they are already moving in that direction with the newbus driver
interface. It really simplifies converting your driver to a kld if
you write it properly. Now a perfect addition would be a daemon or
something that takes care of loading/unloading all of them so that the
user doesn't have to f
Well, they did away with kerneld, but not the concept. Most of the
distributions have moved onto a more sophisticated utility that does the
job.
Alfred Perlstein had the audacity to say:
> I thought Linux did away with thier kerneld concept. Afaik we can
> currently load a kld from within kernel
* Coleman Kane <[EMAIL PROTECTED]> [000604 10:51] wrote:
> Would the person or person(s) interested in developing a kerneld-like, dynamic
> module (un)loader for FreeBSD please email me. I am really interested in this.
> It would be very advantageous to begin to move kld module use into the
> main
Would the person or person(s) interested in developing a kerneld-like, dynamic
module (un)loader for FreeBSD please email me. I am really interested in this.
It would be very advantageous to begin to move kld module use into the
mainstream for all components. I'd like to do what I can to help with
62 matches
Mail list logo
