Re: kerneld for FreeBSD
* 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 > mainstream for all components. I'd like to do what I can to help with it. 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? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 context, can you please > explain further what you want to do? > > -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I > have the heart of a child; I keep it in a jar on my desk." > -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu PGP signature
Re: kerneld for FreeBSD
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 fill a script with kld(un)load commands. Bob K had the audacity to say: > > 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) > > -- Bob <[EMAIL PROTECTED]> "Reality is the only word in the language > that should always be used in quotes" - The Amityville Horror III > -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu PGP signature
Re: kerneld for FreeBSD
> > 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 it. > > 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? 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) -- Bob <[EMAIL PROTECTED]> "Reality is the only word in the language that should always be used in quotes" - The Amityville Horror III To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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_ device drivers... -- Bill Fumerola - Network Architect / Computer Horizons Corp - CVM e-mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 that the > user doesn't have to fill a script with kld(un)load commands. 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 PROTECTED] Hmmm - I have to go check this. My reality assumptions are shattered. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 PROTECTED] > > Hmmm - I have to go check this. My reality assumptions are shattered. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu PGP signature
Re: kerneld for FreeBSD
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, mount). The kernel can also load modules from KLD files "on its own" via kern_linker.c:linker_load_file(). An example of usage is in vfs_syscalls.c:mount(), where if a specified file system configuration structure (vfsconf) is not found in the list of 'configured' file systems, mount(2) attempts to load a module for the file system, if one exists. -- |Chris Costello <[EMAIL PROTECTED]> |Debugger: A tool that substitutes afterthought for forethought. `--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: kerneld for FreeBSD
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 module by it self. so this piece of code should be removed to make ``kerneld'' work 3) interfaces (by name). ``ifconfig'' is able to load appropriate module. again this should be removed TODO: - dynamic unloading in not yet implemented. - not all kld's can be unloaded (see PSEUDO_DEVICE) - need to find out a way to determine which module can be unloaded (ref count?) - ??? thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: kerneld for FreeBSD
> 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 me :-) 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 2) kernel/user space does not unload modules, unless you unload it manually 3) we can not configure which module should be loaded. it is hardcoded so, when i started to code ``kerneld'', i was thinking about 1) one simple interface to load all modules from kernel 2) ability to determine which module can be unloaded and unload it 3) flexible configuration file and, yes, Linux guys have abandoned ``kerneld'', but they do not need it :-) look for KERND define in new Linux kernel. the way they load kernel module is 1) create new kernel thread 2) run /sbin/depmod (or something like this) in the thread 3) wait for thread finished and check for result it does not look like kernel code, indeed :) looks like daemon code :) thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
> > 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 me :-) > > 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'm not entirely keen on having this thrown away; especially since all you'd be doing would be replacing it with code which would invoke the kernel daemon. > 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) > 3) we can not configure which module should be loaded. > it is hardcoded Since the code knows what it wants, this isn't necessarily a bad thing either. In most cases, part of the module name is actually parametric, eg. in the ifconfig(8) case, so this isn't as much of a problem as it sounds. Basically, I think that the current practice of demand-loading modules from inside the kernel is the way to go. There are a couple of cases where pushing them in from the outside (ifconfig, usb, pccard) works, but in each case these already have tools suited to the job. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: kerneld for FreeBSD
[...] > > 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'm not entirely keen on having this ifconfig(8) uses kldfirstmod(2), kldnext(2) etc. to check if the required interface module in the memory or not. all mount_???(8) utilities use getvfsbyname(3), vfsisloadable(3) and vfsload(3) interface, which makes kernel code useless (kernel will never execute this code). > thrown away; especially since all you'd be doing would be > replacing it > with code which would invoke the kernel daemon. > > > 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) > > > 3) we can not configure which module should be loaded. > > it is hardcoded > > Since the code knows what it wants, this isn't necessarily a > bad thing > either. In most cases, part of the module name is actually > parametric, > eg. in the ifconfig(8) case, so this isn't as much of a problem as it > sounds. > > Basically, I think that the current practice of > demand-loading modules > from inside the kernel is the way to go. There are a couple of cases > where pushing them in from the outside (ifconfig, usb, > pccard) works, but > in each case these already have tools suited to the job. > > -- > \\ Give a man a fish, and you feed him for a day. \\ Mike Smith > \\ Tell him he should learn how to fish himself, \\ > [EMAIL PROTECTED] > \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: kerneld for FreeBSD
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) another option in config file? something like ``do_not_unload''? > > 3) we can not configure which module should be loaded. > > it is hardcoded > > Since the code knows what it wants, this isn't necessarily a > bad thing > either. In most cases, part of the module name is actually > parametric, > eg. in the ifconfig(8) case, so this isn't as much of a problem as it > sounds. i do not agree :-) code wants device driver/interface/filesystem/. code should not care about module name. of course it is better to have name convension, but i think this is not the case. :-) thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _< \_ _>(_) (_)/<_\_| \ _|/' \/ (_)>(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
> 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 any metric other than one determined by the module itself to indicate "unuse", and if a module wants to unload itself due to "unuse", it can already do so. I don't want or need a daemon to do this. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: kerneld for FreeBSD
> > 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 if a module wants to unload > itself due to so you point is that we could put a "use/unuse" logic inside each of kernel module. is that correct? even if different kernel modules implement device drivers for the same class of hardware? network interfaces (cards) for example. i would say if interface is marked as ``down'', has no IP, has no references in routing table/firewall, it could be considered as ``gone''. another problem here is that you can use the same module/device right after you have unloaded it. that is a different kind of problem. and, IMHO, it should be solved at configuration level. or even in module itself. for example PSEUDO_DEVICE modules. as far as i know they can not be unloaded. as far as i know sun solaris is able to load/unload dynamicaly kernel modules. and module itself does not perform any attempts to verify its "use/unuse". > "unuse", it can already do so. I don't want or need a daemon > to do this. thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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-modules > > Or? > > I have no faith at all any metric other than one determined by the module > itself to indicate "unuse", Did I suggest kldunload --unused-modules -f ? I didn't think so. > 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. Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _< \_ _>(_) (_)/<_\_| \ _|/' \/ (_)>(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 audacity to say: > > 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 Systems > [EMAIL PROTECTED] > -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
> > 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 the admin wants to
remove a module, great.
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.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
> 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?" Er, no offence, but you're not making any sense. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
* 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 off... that's what > I'm talking about. Oh, I see, too me it seems like a lot of work for not that much gain, nowadays with pnp and pci the reasource conflict game isn't nearly as bad. However if you come up with a design/implementation based on the current source I'm sure people would like to see it. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
* 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 one is off... that's what I'm talking about. > > "Some resources?" Er, no offence, but you're not making any sense. non shareable ISA irqs? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
> * 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 one is off... that's what I'm talking about. > > > > "Some resources?" Er, no offence, but you're not making any sense. > > non shareable ISA irqs? They're "non shareable" at the hardware level ... like all the "non shareable" hardware resources. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 a third party? ("kerneld") If the admin wants to
> remove a module, great.
That was the point I was trying to make. If the admin wants to
remove modules manually he can do so. If he wants to have it
happen periodically he can set up a cron job to do it. You would
just need to add an option to kldunload that unloads all unused
modules. You didn't read very well, I never promoted "kerneld".
This last comment referred to
> and if a module wants to unload itself due to
> "unuse", it can already do so.
because modules should not unload themselves, it's up to the
admin to decide.
Cheers,
Jeroen
--
Jeroen C. van Gelderen o _ _ _
[EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_)
_< \_ _>(_) (_)/<_\_| \ _|/' \/
(_)>(_) (_)(_) (_)(_)' _\o_
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
RE: kerneld for FreeBSD
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 of kernel module. is that correct? even if different > kernel modules implement device drivers for the same class > of hardware? network interfaces (cards) for example. i would > say if interface is marked as ``down'', has no IP, has no > references in routing table/firewall, it could be considered > as ``gone''. No, in general it is not desirable, because it will require hardware reprobe operation on the next load. For PCCARDs we already have pccardd(8) which can be integrated into devd at some point. The whole idea of kerneld sounds unreasonable to me. It is completely unneeded for servers and may have only limited use for FreeBSD based workstations. More to the point - for some machines I'm compile all required modules into a single (or two) KLDs - in this case kerneld will not be helpful at all. Remember, KLD != module. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 interface, and typically nothing at the hardware level causes a system to crash when resources are shared. It is usually a driver expecting information from its device, when another one is already using a certain interrupt. The only counter to this is MIO and PIO, where the result of an input is undefined, and an output is supposed to cause the data to go to both devices. I was actually aiming more towards, memory allocations, and other things like MTRRs and X and stuff. From the MTRR standpoint, most 6th gen processors (for the sake of argument the K6CXT is 6th gen) have MTRRs, registers that can define how memory ranges are utilized in the processor. There are only a finite number of these, therefore if you were to disable them for some hardware that didn't need them you could spread them out. It would also be really great (and I was originally not informed about the current state of autoloading/unloading of modules for fs and net devices) to move completely to loading everything out of klds, rather than compiling the kernel. It may also help some debugging to be able to pull apart the kernel peice by peice, having a basic default "failsafe" kernel to boot from that would subsequently begin to load the necessary modules specified, or to load them in real time and unload them when finished. I really am not sure about the reality of this proposal, and someone brought it up earlier, so I thought I'd stick my head in on it. This email is getting rather lengthy, maybe I'll try fiddling with something tonight... school is over until summer quarter starts. Mike Smith had the audacity to say: > > They're "non shareable" at the hardware level ... like all the "non > shareable" hardware resources. > -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu PGP signature
Re: kerneld for FreeBSD
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 Smith had the audacity to say: > > > 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?" Er, no offence, but you're not making any sense. > -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu PGP signature
RE: kerneld for FreeBSD
[...] > > > 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? :-) what is wrong with that? it would be so nice to have small GENERIC kernel and bunch of modules. kernel will start, identify all hardware (pci/pnp) and than load appropriate modules. the only problem here is old hardware :( [...] > > i do not agree :-) code wants device > driver/interface/filesystem/. > > code should not care about module name. of course it is > better to have > > name convension, but i think this is not the case. :-) > > This is debatable; mount, for example, knows the name of its > plugins. So > does PAM. Kernel modules are just plugins that go somewhere else. let say i'm a third party vendor. i developed new hardware and driver for FreeBSD (of course KLD module). i do not want to give my source code to anybody. so you have the following options: 1) go ahead and try to convince me to use the same name convention 2) just ignore this hardware/driver/vendor 3) wait until somebody writes an ``open source'' driver 4) try do something to make in work (could be as easy as rename) 5) ??? thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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.
Randell Jesup had the audacity to say:
> Lack of this has (in my mind) long been one of the primary failings
> of most Unix's, at least in heterogenous environments like PC's (and just
> about any machine with significant hardware expansion capabilities).
> Modern machines not only add hardware when being built, but between boots,
> and even in the middle of a session (USB, 1394, etc). A dynamically-loaded
> driver system is the obvious choice. This would make it far simpler for
> users to configure machines (and add and remove hardware), to distribute
> drivers, etc. IMHO, of course.
>
> Historical reference:
> The Amiga introduced hardware "Autoconfig" 15 years ago; and not
> horribly long after that Mach had some form of loadable drivers (correct me
> if I'm wrong; I know it had user-mode filesystems - I only observed Mach
> from a distance outside of playing a little with a 1st-gen nExt).
>
> --
> Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
> [EMAIL PROTECTED]
>
--
Coleman Kane
President,
UC Free O.S. Users Group - http://pohl.ececs.uc.edu
PGP signature
RE: kerneld for FreeBSD
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 > hardware (pci/pnp) and than load appropriate modules. the only problem > here is old hardware :( 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 use". Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 > use". Doesn't Solaris auto-unload unused drivers when memory gets tight? -- Ben 220 go.ahead.make.my.day ESMTP Postfix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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. -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
+[ 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 when there are no more of those File Sytems mounted? -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 freebsd, without needing to reboot. Bosko Milekic had the audacity to say: > > An Operating System should only do that when the administrator is so > stupid that he/she actually loads "unused" drivers. > > -- > Bosko Milekic > [EMAIL PROTECTED] -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu PGP signature
Re: kerneld for FreeBSD
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 module previously allocated will be freed? Hmm, do the following several times (n*100, n*1000): hostname# kldload cd9660; kldunload cd9660 More and more wired memory will be allocated but not freed. If you perform this cycle too many times, the machine will lock up or reboot. Björn -- -BEGIN GEEK CODE BLOCK- GCS d--(+) s++: a- C+++(-) UBOSI$ P+++(-) L---(++) !E W- N+ o>+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 advantages of FreeBSD is its robustness and reliability, then one generally does not want to go loading and unloading modules all the time. A 'kerneld' like gizmo for FreeBSD would be a waste of time. The scheme we have now -- having the utility programs load the modules on the fly (ifconfig, vnconfig, etc...) works wonderfully. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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. While I believe it's the sysadmin's choice whether to unload modules, it's also hir choice as to whether to run a daemon that'll auto-unload unused modules. That part of your idea I can understand. I'd imagine it'd work great as a port. > 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 > freebsd, without needing to reboot. You can already do this. kldunload the old module, and kldload the new module. Or am I missing something again? Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 kld operations. If one of the biggest > advantages of FreeBSD is its robustness and reliability, then one > generally does not want to go loading and unloading modules all the > time. I think that's unrealistic for end-user machines. In a world of removable PCcards, USB devices, etc, expecting that the GENERIC kernel include code for all of them leaves us in a fairly unscalable place. As the rest of the world moves towards not requiring a recompile to add a more obscure ethernet card, we should not be moving in the opposite direction. Don't get me wrong -- I'm all for a more secure system, but securelevels don't really solve the problem, and can't address the type of issue you describe. If you take a look at Tim Fraser's lomac paper from the recent Oakland conference, it strongly suggests that a traditional MAC policy can (with a high degree of compatibility) provide exactly the kind of protection that securelevels can not :-). The recent POSIX.1e-related capability interfaces have been added so that those working on support for MAC models on FreeBSD can rely on them. As such, there is substantial hope (and intent) that similar MAC models (Biba, MLS) will be available on FreeBSD in the near future. > A 'kerneld' like gizmo for FreeBSD would be a waste of time. The > scheme we have now -- having the utility programs load the modules > on the fly (ifconfig, vnconfig, etc...) works wonderfully. 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 be provided to hundreds of them (even huge beasts like ppp). If requests for kernel functionality loads come through a well-audited (both senses) and well-defined LPC mechanism, there is substantially less risk involved. In a world where dynamic kernel module loading occurs even after entering secure, multi-level operation, that type of protection seems like a good idea. It would allow us to distinguish the following privileges: 1 Right to request specific functionality be loaded 2 Right to load the functionality 3 Right to invoke the functionality Letting, say, ppp have (1) and (3) but not (2) provides a substantial security improvement, while retaining the ability to introduce new functionality at run-time. 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 LPC channel over a UNIX domain socket) would not be that hard. Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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, there are many people who use FreeBSD for desktop or home situations and even those who don't know a extremely large amount about computer hardware and all. This would be a nice "option" to have for some. Neil Blakey-Milner had the audacity to say: > > 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 > > freebsd, without needing to reboot. > > You can already do this. kldunload the old module, and kldload the new > module. Or am I missing something again? > > Neil > -- > Neil Blakey-Milner > Sunesi Clinical Systems > [EMAIL PROTECTED] > -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 liking to manually load a good deal of > those. Plus, there are many people who use FreeBSD for desktop or home > situations and even those who don't know a extremely large amount > about computer hardware and all. This would be a nice "option" to have > for some. If you're suggesting more modularity, that's great. You just confused me by mentioning "kerneld". I'm all for more modules. I still had problems with why you wanted a 'kerneld', but rwatson's suggestions about security, pccardd, usbd, do make sense. I do like the way the auto-ifconfig and auto-mount stuff works, though. At the very least, I'd like a probe-only way to find out what devices are available, given a bunch of device driver modules. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
> 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 multi-user desktop/workstation systems, but it kind of really sucks for my laptop, which has device drivers coming/going on a regular basis as I insert/remove cards on the fly. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 device driver while running freebsd, > without needing to reboot. Another note on the loadable/unloadable driver tip: SCSI, USB, and Firewire are all adaptable bus architectures that allow you to add and remove devices from your system at will. There are dozens of situations in which you might wish to hot swap devices. If I, for sake of argument, wanted to remove one of my SlowAssDrive2000 disks from my server and replace it with a NiftyFastDrive2001, why should I have to reboot? Why shouldn't the server automatically unload the driver if the bus protocol gives me registration/deregistration information? I guess I don't see the harm in a ref count system for device drivers on hot swappable bus architectures. Does anyone want to see a tiny FreeBSD kernel that pulls in drivers via an /etc/system style configuration file? Let's stop attacking these ideas as foreign evil and start looking for any interesting notions that we can use. Thanks, -- Jack Rusher, Senior Engineer | mailto:[EMAIL PROTECTED] Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 be provided to hundreds of > them (even huge beasts like ppp). If requests for kernel functionality > loads come through a well-audited (both senses) and well-defined LPC > mechanism, there is substantially less risk involved. In a world where > dynamic kernel module loading occurs even after entering secure, > multi-level operation, that type of protection seems like a good idea. It > would allow us to distinguish the following privileges: > > 1 Right to request specific functionality be loaded > 2 Right to load the functionality > 3 Right to invoke the functionality > > Letting, say, ppp have (1) and (3) but not (2) provides a substantial > security improvement, while retaining the ability to introduce new > functionality at run-time. Wow, for the first time someone makes a *GOOD* case for kerneld! -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Hmmm - I have to go check this. My reality assumptions are shattered. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: kerneld for FreeBSD
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 sourceforge.net CVS tonight. thanks everybody, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 currently not in use. Not unused in the sense of useless, but in the sense of not currently active. -- Ben 220 go.ahead.make.my.day ESMTP Postfix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
> 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 currently not in use. Not unused in the sense of > useless, but in the sense of not currently active. This is just a Really Pointless Idea. There are so many more useful and interesting things to get done... *sigh* -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 that can load modules and all itself, or at the very least, a mechanism to manage the growing number of modules in the kernel. Anyway, the questions we should ask are: What are the shortcomings of the current kld 'module' system? What type of support would we like to see? Neil Blakey-Milner had the audacity to say: > If you're suggesting more modularity, that's great. You just confused > me by mentioning "kerneld". I'm all for more modules. > > I still had problems with why you wanted a 'kerneld', but rwatson's > suggestions about security, pccardd, usbd, do make sense. I do like the > way the auto-ifconfig and auto-mount stuff works, though. > > At the very least, I'd like a probe-only way to find out what devices > are available, given a bunch of device driver modules. > > Neil > -- > Neil Blakey-Milner > Sunesi Clinical Systems > [EMAIL PROTECTED] > -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
> 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 > advantages of FreeBSD is its robustness and reliability, then one > generally does not want to go loading and unloading modules all the > time. > > A 'kerneld' like gizmo for FreeBSD would be a waste of time. The > scheme we have now -- having the utility programs load the modules > on the fly (ifconfig, vnconfig, etc...) works wonderfully. > 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 EVER really be noticed by the 83Tb chunk that Nutscrape allocates. Excuse me, I must now think back to the dumbness achieved by people re-compiling Linux completely statically in hopes that it'll speed up their systems by not dynamically loading the libraries These were the same guys who wanted to unload modules to save kernel RAM... --mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 > EVER really be noticed by the 83Tb chunk that Nutscrape allocates. > > Excuse me, I must now think back to the dumbness achieved by people > re-compiling Linux completely statically in hopes that it'll speed up > their systems by not dynamically loading the libraries These > were the same guys who wanted to unload modules to save kernel RAM... The issue is with really small ram embedded systems. Making things CAPABLE of being small is different from making them dynamicly loadable. > > --mike -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
> 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 > > EVER really be noticed by the 83Tb chunk that Nutscrape allocates. ... > 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 nondeterminism that "automatically" (read 'randomly') unloading modules would involve. It's simple; a kernel-module-handling-daemon does not have anything to offer us at this time. We don't need one; the problems it might be applied to solve have already been solved differently, and we are (generally) happy with the results. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 with which to load these drivers from whatever may use them, there probably isn't a need after all for this sort of thing, so I'm done thinking about it, on to more pertinent things... Mike Smith had the audacity to say: > Nobody in their right mind is going to produce a "really small ram" > embedded system that features the sort of nondeterminism that > "automatically" (read 'randomly') unloading modules would involve. > > It's simple; a kernel-module-handling-daemon does not have anything to > offer us at this time. We don't need one; the problems it might be > applied to solve have already been solved differently, and we are > (generally) happy with the results. > > -- > \\ Give a man a fish, and you feed him for a day. \\ Mike Smith > \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] > \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 nondeterminism that > "automatically" (read 'randomly') unloading modules would involve. Actually, embedded programmers are more likely to link everything in the kernel so they don't have to worry about calling drivers that aren't loaded. A pretty conservative lot, in general. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
> > > 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 > > > EVER really be noticed by the 83Tb chunk that Nutscrape allocates. > ... > > 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 nondeterminism that > "automatically" (read 'randomly') unloading modules would involve. Gee, I guess you better tell the QNX folks that, who've been doing such things for as long as you've been programming. Everyone is an idiot or a completely lunatic if they don't agree with you completely? >From the last week... > The bulletheads will brand me a "libertarian" (not really correct), > any sort of mandate to turn the Project into a bannana republic; all > this talk going on is breeze between a small group of windy > individuals who appear to be deluding themselves into thinking they > speak for the rest of the community. > I think that you're incredibly naive. > This is all insane speculation, and totally off the mark. > Many Americans think their version of democracy works fine, too. > This is just a Really Pointless Idea. > Nobody in their right mind is going to produce ... Seems like everything is black/white for you lately Mike. Thought about taking a vacation to cool off and relax? Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
> > > > 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 > > > > EVER really be noticed by the 83Tb chunk that Nutscrape allocates. > > ... > > > 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 nondeterminism that > > "automatically" (read 'randomly') unloading modules would involve. > > Gee, I guess you better tell the QNX folks that, who've been doing such > things for as long as you've been programming. Everyone is an idiot or > a completely lunatic if they don't agree with you completely? Since FreeBSD isn't QNX, and entirely lacks the infrastructure that they have for this sort of thing, I don't get where you're going here. We _are_ talking about FreeBSD here, not QNX, right? If that's the case, my point stands - trying to "automatically unload unused modules" in the FreeBSD context simply isn't sufficiently deterministic or robust for this argument to be valid. There's too much "this would be good for X case" arguing going on, where the proponent clearly hasn't thought much about the X case other than that it sounds cool and might add some weight to their otherwise unrelated pet cause. "Really small embedded systems" appear to be the Cool Cause Du Jour. > Seems like everything is black/white for you lately Mike. Thought about > taking a vacation to cool off and relax? Let me know how yours is doing you, and I might consider it. How many years has it been now? 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 LPC channel over a UNIX domain : socket) would not be that hard. I personally think that a devd would be great to have. One that could do things when devices arrive and leave as well as when the removable hardware/software detects a new hunk of hardware that doesn't attach to any resident driver. It would be extremely useful if only the specific driver that was for that hardware wound up in the kernel. It would also be useful if that module were unloaded when that removable device went away. No need to keep it in memory, so long as there was a way to bring it back later. Sure, there's a monster bug in the kldload/unload right now where that eats wired memory. That bug should be fixed. Finally, all of this would be less of an issue if one could page the kernel, or at least parts of it... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 vm_page_t vm_add_new_page(vm_offset_t pa); This can be used to reclaim the space consumed by preloaded files. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 consumed by preloaded files. Maybe it was something a driver of mine did then, since in 4.0-stable I have observed that multiple load/unload of the driver caused a memory leak that was about the same size as the text/data sections of the driver. Maybe I had a leak in my code instead... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
> 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 when is a tough question, but since 4.0, I think, for NICs, and > > > certainly at least 3.x, maybe even 2.x, for fs. > > > > cvs log ifconfig.c says revision 1.44 which is after RELENG_3_4_0_RELEASE > > ... > > RELENG_4_0_0_RELEASE: 1.51 > > ... > > RELENG_3_4_0_RELEASE: 1.38.2.2 > > ... > > revision 1.44 > > date: 1999/09/20 07:58:08; author: msmith; state: Exp; lines: +45 -1 > > If we don't appear to have a module loaded supporting the interface > > we're about to operate on, try to load one. Don't complain if the > > load fails, and always press on regardless (there may not be a module > > suitable or required). > > > > With the renaming of the PCI ethernet driver modules and the addition > > of appropriate miibus dependancies on those modules that need it, it is > > now no longer necessary to compile many ethernet drivers into the kernel; > > they will be loaded on demand the first time they are ifconfig'ed. > > 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.255.0" > defaultrouter="216.231.50.1" > > So I put the drivers back in the kernel. another solution would be to load it a boot time using if_xl_load="YES" in /boot/loader.conf. I don't remember which version of FreeBSD are you running, is it 4.0-STABLE ? PS : I put back this message in the mailing lists multimedia & hackers. Cyrille. -- home: mailto:[EMAIL PROTECTED] work: mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
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 to be compiled into the > > > > > kernel. > > > > > > > > Since when is a tough question, but since 4.0, I think, for NICs, and > > > > certainly at least 3.x, maybe even 2.x, for fs. > > > > > > cvs log ifconfig.c says revision 1.44 which is after RELENG_3_4_0_RELEASE > > > ... > > > RELENG_4_0_0_RELEASE: 1.51 > > > ... > > > RELENG_3_4_0_RELEASE: 1.38.2.2 > > > ... > > > revision 1.44 > > > date: 1999/09/20 07:58:08; author: msmith; state: Exp; lines: +45 -1 > > > If we don't appear to have a module loaded supporting the interface > > > we're about to operate on, try to load one. Don't complain if the > > > load fails, and always press on regardless (there may not be a module > > > suitable or required). > > > > > > With the renaming of the PCI ethernet driver modules and the addition > > > of appropriate miibus dependancies on those modules that need it, it is > > > now no longer necessary to compile many ethernet drivers into the kernel; > > > they will be loaded on demand the first time they are ifconfig'ed. > > > > 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.255.0" > > defaultrouter="216.231.50.1" > > > > So I put the drivers back in the kernel. > > another solution would be to load it a boot time using if_xl_load="YES" > in /boot/loader.conf. > > I don't remember which version of FreeBSD are you running, is it > 4.0-STABLE ? > > PS : I put back this message in the mailing lists multimedia & hackers. forgive this message, I fu2 this message to the wrong lists, sorry. indeed, fu2 stable. Cyrille. -- home:mailto:[EMAIL PROTECTED] Supprimer "no-spam." pour me repondre. work:mailto:[EMAIL PROTECTED] Remove "no-spam." to answer me back. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kerneld for FreeBSD
> > > > 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.255.0" > > defaultrouter="216.231.50.1" > > > > So I put the drivers back in the kernel. If you want the module to be autoloaded, you also need to add it to the network_interfaces varable, eg. network_interfaces="xl0 lo0" As otherwise the startup scripts don't know to do anything about it. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
