Date: Fri, 22 Feb 2002 07:51:29 +0100 From: Cliff Sarginson <csfbsd@raggedclown.net> To: questions@freebsd.org Subject: Re: Kernel loader Message-ID: <20020222065129.GA422@raggedclown.net> In-Reply-To: <15477.34969.572893.76786@guru.mired.org> References: <89637344@toto.iv> <15477.34969.572893.76786@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 21, 2002 at 05:54:01PM -0600, Mike Meyer wrote: > Cliff Sarginson <csfbsd@raggedclown.net> types: > > Well, I tried this out in -hackers, and got a couple of mono-syllabic > > replies, but no-one answered my question. So I will try it here. > > Gee, I wouldn't answer on -hackers because I figured someone who knew > the answers better than I would answer. Oh well... > > > The kernel loader code has mechanisms to implant dependencies in the > > module code, e.g. if module A requires module B, then you can build > > this knowledge into module A. > > That's correct. > > > Now I do not believe that if you load module A, then module B is > > automagically loaded as well. Looking at the program kldload it > > is just a few lines that just invokes a system call to load the > > module requested. I think the system call code should be in my > > source tree somewhere but I am damned if I can find it. > > Your belief is incorrect. Well, it's incorrect for elf modules. I > don't know about other formats because I didn't check them. The source > code you want is in sys/kern/kern_linker.c and link_elf.c. > > > What I was getting at is that in Linux they have this 'depmod' > > setup that creates a dependency list, so that loading a module > > should load all other required modules. I am looking for the > > same functionality in FreeBSD. I do not believe it exists. > > You may be looking for gensetdefs. It's used in dealing with > dependency lists in /usr/src/sys/conf/kmod.mk. It looks like the > gensetdefs man page is out of date, though. However, if you're going > to write a kld, you really don't care. > > > Can anyone confirm this, or refute it. > > I'm not sure which I did, but I think I answered your question. > > > My second question was this. > > It seems to me that the kernel module loading may have some > > sensitivity over the point at which it is loaded. I have reported > > a bug in drm-kmod and my tests seem to show that it makes a > > difference when a particular module (in this case "agp") is loaded > > early on in the boot process via loader.conf, or later on by a shell > > command in /usr/local/etc/rc.d. Is this likely to be expected ? > > I can't really help here, because I'm not that intimate with PC > hardware. However, I know that BSD has run on hardware on which it > mattered which order devices were allocated. Basically, if something > that can use anything grabs what it thinks is best, then something > needing a specific flavor or amount comes along, the second one may > work if allocated first, and fail if allocated second. Just to make > matters interesting, if you probed for them in the order that > allocation worked, the probe didn't work, and vice versa. > > > I got zero answers to this question. > > > > If it does make a difference then I would be so bold as to say that > > on-demand kernel loadable modules are not on-demand kernel loadable > > modules if they cannot be loaded after the main boot process is > > complete...and therefore you may as well build them into the kernel > > in the first place. > > It may be that whether or not you can load them after the main boot > process completes depends on what gets loaded by the main boot > process. So that on some kernel configs it works fine as a kld, and on > others it doesn't work because some resource it needs is no longer > available. Ok. I would say then that the module in question should not be a seperately loadable module, but must be required to be built into the kernel, or loaded not later than in loader.conf > Thanks Mike ! That is a complete answer to my question(s). I should have asked here in the first place :) My follow up question is why dependent modules cannot be loaded automagically, but with what you have told me I may be able to look further into that myself. To be honest, I am not entirely sure what the use is of planting this dependency information if it is not used to do such a thing. It means you have to know something which the O/S is already capable of working out for you. The only other answer is that you have to tell the kernel in advance what a module is going to use for some other reason, although why escapes me at this early hour. It makes it doubly difficult when you discover that LINT is incomplete. It does not mention every module..there is not a peep in it about "agp" for example. This is my first foray into some deeper understanding of how the kernel works in FreeBSD, and in this regard there is a rather large hole in available documentation. There is the book on the 4.4BSD implementation which is 6 years old in it's latest edition, and quite a lot of documents on this and that scattered around, but there is not a coherent body of documents describing the O/S as it is. Matt Dillon's excellent paper on the VM system is my current bedtime reading; but there are few documents at that level on other aspects. There is a huge gap waiting to be filled here. What if all the hackers fell under a bus at the same time tomorrow ? It is ironic that the best documented UNIX kernel around is Linux, which is a look-alike, although there is also an excellent book on System V .. the author's name escapes me. It is a great deal easier to look at the code that implements an algorithm when you first have some idea what that algorithm is ! I realise that the kernel is in a state of constant change, but surely not in a state of constant re-write. Thanks again, as usual, your clearly written answers to questions go a long way. -- Regards Cliff Sarginson -- <csfbsd@raggedclown.net> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020222065129.GA422>