Re: Path to kernel modules (second attempt)
Jean-Yves Migeon wrote: > On 08.07.2012 16:34, Lars Heidieker wrote: > > I would prefer /kernel as it most closely describes what it is. In that > > move it would be nice if /netbsd and /libdata/firmware would be moved in > > there as well. At least for /netbsd this would be missleading if we go > > with /modules eg. > > Sure that /kern is a prefix is not that nice, but I don't mind. > > > > What else beside firmware is in /libdata > > Nothing more. > > If we go for /kernel or /boot, could we move the kernel inside that > directory then? It will not make sense to have it remain under /netbsd > or /netbsd.gz. Yes, I think that would be a way to go. However, it is not necessary for netbsd-6, we can do it after. -- Mindaugas
Re: Path to kernel modules (second attempt)
On 08.07.2012 16:34, Lars Heidieker wrote: > I would prefer /kernel as it most closely describes what it is. In that > move it would be nice if /netbsd and /libdata/firmware would be moved in > there as well. At least for /netbsd this would be missleading if we go > with /modules eg. > Sure that /kern is a prefix is not that nice, but I don't mind. > > What else beside firmware is in /libdata Nothing more. If we go for /kernel or /boot, could we move the kernel inside that directory then? It will not make sense to have it remain under /netbsd or /netbsd.gz. -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: Path to kernel modules (second attempt)
On Jul 8, 2012, at 10:20 AM, Matthew Mondor wrote:
> On Sun, 8 Jul 2012 17:57:00 +0200
> Edgar Fuß wrote:
>
>>> Please not /kernel as it was already mentioned, it is too similar to
>>> /kern.
>> What about /netbsd? E.g. /netbsd/6.0_BETA/{modules,kernel,firmware}.
>
> /netbsd/amd64/6.0/GENERIC/{modules,kernel,firmware} :) ?
One more note about FreeBSD's structure. In addition to looking in
/boot/$KERNNAME, it will also look in /boot/modules. This is done so that you
can have multiple different kernels of the same version, that might use
different internal KBIs that 3rd party drivers don't use. You can install your
3rd party driver into /boot/modules and load it with successive kernels (we
move /boot/kernel to /boot/kernel.old before recreating the /boot/kernel to
install the new kernel and modules). This works well for similar versions (eg
9.0, 9.1), but works less well with 8.x->9.x.
> But can the kernel easily detect that its image was booted in a
> particular directory, and use that as base directory to look for
> modules? Also, how more complex would this be for the bootloader that
> also needs to preload a few modules to be able to boot?
FreeBSD's boot loader passes this in...
Warner
Re: Path to kernel modules (second attempt)
On Sun, 8 Jul 2012 17:57:00 +0200
Edgar Fuß wrote:
> > Please not /kernel as it was already mentioned, it is too similar to
> > /kern.
> What about /netbsd? E.g. /netbsd/6.0_BETA/{modules,kernel,firmware}.
/netbsd/amd64/6.0/GENERIC/{modules,kernel,firmware} :) ?
But can the kernel easily detect that its image was booted in a
particular directory, and use that as base directory to look for
modules? Also, how more complex would this be for the bootloader that
also needs to preload a few modules to be able to boot?
--
Matt
Re: Path to kernel modules (second attempt)
> Please not /kernel as it was already mentioned, it is too similar to
> /kern.
What about /netbsd? E.g. /netbsd/6.0_BETA/{modules,kernel,firmware}.
Re: Path to kernel modules (second attempt)
On 07/08/2012 04:17 PM, Mindaugas Rasiukevicius wrote: > Bernd Ernesti wrote: (I know there's an argument that if it's /kernel we could eventually put other stuff in there as well besides modules; but all such uses are so far entirely conjectural (not even to the stage of being vaporware) so I think it's highly premature to plan for them at this point.) >>> >>> Is there a reason to *not* go with /kernel, besides annoyance of it >>> being similar to /kern? [..] >> >> Please not /kernel as it was already mentioned, it is too similar to >> /kern. Filename completion would be not easier if you want to use a >> file from /kern. > > I do not really see that as a real problem. Slight annoyance - yes. > >> Either somewhere below /libdata or if you really want a new toplevel >> directory then it could be /boot which was mentioned, so it match the >> FreeBSD behaviour. > > Kernel modules are not just miscellaneous data blobs. As for matching, > the same argument can apply to /kernel, which is matching Solaris (also, > our modload/modstat/modunload utilities are ~matching Solaris/SunOS). > There is not that much point in matching, however, as we use a different > structure anyway. > I would prefer /kernel as it most closely describes what it is. In that move it would be nice if /netbsd and /libdata/firmware would be moved in there as well. At least for /netbsd this would be missleading if we go with /modules eg. Sure that /kern is a prefix is not that nice, but I don't mind. What else beside firmware is in /libdata Lars -- Mystische Erklärungen: Die mystischen Erklärungen gelten für tief; die Wahrheit ist, dass sie noch nicht einmal oberflächlich sind. -- Friedrich Nietzsche [ Die Fröhliche Wissenschaft Buch 3, 126 ]
Re: Path to kernel modules (second attempt)
Bernd Ernesti wrote: > > > (I know there's an argument that if it's /kernel we could eventually > > > put other stuff in there as well besides modules; but all such uses > > > are so far entirely conjectural (not even to the stage of being > > > vaporware) so I think it's highly premature to plan for them at this > > > point.) > > > > Is there a reason to *not* go with /kernel, besides annoyance of it > > being similar to /kern? [..] > > Please not /kernel as it was already mentioned, it is too similar to > /kern. Filename completion would be not easier if you want to use a > file from /kern. I do not really see that as a real problem. Slight annoyance - yes. > Either somewhere below /libdata or if you really want a new toplevel > directory then it could be /boot which was mentioned, so it match the > FreeBSD behaviour. Kernel modules are not just miscellaneous data blobs. As for matching, the same argument can apply to /kernel, which is matching Solaris (also, our modload/modstat/modunload utilities are ~matching Solaris/SunOS). There is not that much point in matching, however, as we use a different structure anyway. -- Mindaugas
Re: Path to kernel modules (second attempt)
On Sun, Jul 08, 2012 at 01:03:03PM +0100, Mindaugas Rasiukevicius wrote:
> David Holland wrote:
> > On Sat, Jul 07, 2012 at 08:57:10PM +0100, Mindaugas Rasiukevicius wrote:
> > > Regarding the PR/38724, I propose to change the path to "/kernel/".
> > > Can we reach some consensus quickly for netbsd-6?
> >
> > If it's going to be a new toplevel directory, it should probably be
> > /modules.
>
> I do not mind /modules. It is better than /lib{data,exec,}/modules.
> However..
Do we really need a new toplevel directory?
> > (I know there's an argument that if it's /kernel we could eventually
> > put other stuff in there as well besides modules; but all such uses
> > are so far entirely conjectural (not even to the stage of being
> > vaporware) so I think it's highly premature to plan for them at this
> > point.)
>
> Is there a reason to *not* go with /kernel, besides annoyance of it
> being similar to /kern? [..]
Please not /kernel as it was already mentioned, it is too similar to
/kern. Filename completion would be not easier if you want to use a
file from /kern.
Either somewhere below /libdata or if you really want a new toplevel
directory then it could be /boot which was mentioned, so it match the
FreeBSD behaviour.
Bernd
Re: Path to kernel modules (second attempt)
David Holland wrote:
> On Sat, Jul 07, 2012 at 08:57:10PM +0100, Mindaugas Rasiukevicius wrote:
> > Regarding the PR/38724, I propose to change the path to "/kernel/".
> > Can we reach some consensus quickly for netbsd-6?
>
> If it's going to be a new toplevel directory, it should probably be
> /modules.
I do not mind /modules. It is better than /lib{data,exec,}/modules.
However..
> (I know there's an argument that if it's /kernel we could eventually
> put other stuff in there as well besides modules; but all such uses
> are so far entirely conjectural (not even to the stage of being
> vaporware) so I think it's highly premature to plan for them at this
> point.)
Is there a reason to *not* go with /kernel, besides annoyance of it
being similar to /kern? I think it is still a good reason that we
could put other stuff eventually. It does not mean that we should
start putting immediately, but there is no need to limit ourselves.
On the other hand, /libdata/firmware was mentioned. Personally, I
think it would belong to /kernel/firmware then (I guess the move can
be done in a compatible way as well).
--
Mindaugas
Re: Path to kernel modules (second attempt)
On Sat, 7 Jul 2012 20:54:12 -0600 Warner Losh wrote: > But it kinda fails with multiple kernels. On FreeBSD, we went with > /boot/$KERNNAME/kernel for the kernel, with all the modules associated with > it in /boot/$KERNNAME. By default, we load /boot/kernel/kernel and the loader > may also choose to load other things. The reason we put it in /boot was > because we have a secondary boot loader (/boot/loader) and on some platforms > we were looking at you needed a separate boot partition to do things > correctly. this layout allows for that as well as transparently supporting > multiple kernels. I know on one of my MIPS boards, I can read kernels or the > boot loader off of FAT partitions, so my /boot there is a FAT file system, > with the rest of the system in a UFS file system on separate > partitions/slices on my CF. I think that the version and arch directories would be maintained. But you're right, and when I think of it, it's actually one of the reasons I use monolithic kernels. If modules and kernels always corresponded well and were closely coupled in a directory, it'd be much less trouble for me to test and move kernels around, or maintain multiple versions of them on the same host. At the moment, single monolithic files do this much better. Some kernel configuration changes not only affect the main image, but also the modules, and full ABI compatibility would be a difficult problem. It might not matter for someone who wants to avoid using a custom kernel (I agree that modules should help a lot in this case for the end user, no matter their arrangement). But if we eventually begin to see modules under non-BSD licenses which can only be distributed as modules, more tech users might likely want modules as well... Or it might not matter at all, if an admin can simply link together all modules in a single kernel image, and keep the non-distributable image private in the organization (I think there is some work in this area, other than the traditional monolithic builds)? So something like /kmod/amd64/6.0/GENERIC/, or a layout where /netbsd-GENERIC/ could be a directory, /netbsd-GENERIC/image the kernel, /netbsd-GENERIC/modules/ its corresponding modules, would be nice. In the latter case, prehaps also a /netbsd symlink pointing to the corresponding /foo/image, somewhat like the vmlinuz link of some Linux distributions? Thanks for sharing your experience, -- Matt
Re: Path to kernel modules (second attempt)
On Jul 7, 2012, at 4:17 PM, Matthew Mondor wrote: > On Sat, 07 Jul 2012 22:46:50 +0200 > Jean-Yves Migeon wrote: > >> On 07.07.2012 21:57, Mindaugas Rasiukevicius wrote: >>> Hello, >>> >>> Regarding the PR/38724, I propose to change the path to "/kernel/". >>> Can we reach some consensus quickly for netbsd-6? >> >> /kernel is way to close to /kern, and they serve different purposes. >> IMHO that will raise confusion. > > Perhaps /kmod, or /modules like dholland suggests? > >> Technically modules are not libraries, but maybe /libdata/module is a >> good option? We already have firmwares in /libdata/firmware, and those >> get used by the kernel. > > That also makes sense But it kinda fails with multiple kernels. On FreeBSD, we went with /boot/$KERNNAME/kernel for the kernel, with all the modules associated with it in /boot/$KERNNAME. By default, we load /boot/kernel/kernel and the loader may also choose to load other things. The reason we put it in /boot was because we have a secondary boot loader (/boot/loader) and on some platforms we were looking at you needed a separate boot partition to do things correctly. this layout allows for that as well as transparently supporting multiple kernels. I know on one of my MIPS boards, I can read kernels or the boot loader off of FAT partitions, so my /boot there is a FAT file system, with the rest of the system in a UFS file system on separate partitions/slices on my CF. Just something to think about before you go stuffing it into /lbidata/module or something... Warner
Re: Path to kernel modules (second attempt)
On Sat, 07 Jul 2012 22:46:50 +0200 Jean-Yves Migeon wrote: > On 07.07.2012 21:57, Mindaugas Rasiukevicius wrote: > > Hello, > > > > Regarding the PR/38724, I propose to change the path to "/kernel/". > > Can we reach some consensus quickly for netbsd-6? > > /kernel is way to close to /kern, and they serve different purposes. > IMHO that will raise confusion. Perhaps /kmod, or /modules like dholland suggests? > Technically modules are not libraries, but maybe /libdata/module is a > good option? We already have firmwares in /libdata/firmware, and those > get used by the kernel. That also makes sense -- Matt
Re: Path to kernel modules (second attempt)
Jukka Ruohonen wrote: > On Sat, Jul 07, 2012 at 08:57:10PM +0100, Mindaugas Rasiukevicius wrote: > > Regarding the PR/38724, I propose to change the path to "/kernel/". > > Can we reach some consensus quickly for netbsd-6? > > I'd vote for "/lib/modules" noted in the PR (or maybe under /libdata?) > simply because in my opinion the root hierarchy has already been abused > too much in NetBSD. On the other hand, I don't see anything wrong > with /stand either. We have hier(7) defining top level directories. Kernel modules are neither libraries nor belong to standalone environment in this respect. -- Mindaugas
Re: Path to kernel modules (second attempt)
On Sat, Jul 07, 2012 at 08:57:10PM +0100, Mindaugas Rasiukevicius wrote: > Regarding the PR/38724, I propose to change the path to "/kernel/". > Can we reach some consensus quickly for netbsd-6? If it's going to be a new toplevel directory, it should probably be /modules. (I know there's an argument that if it's /kernel we could eventually put other stuff in there as well besides modules; but all such uses are so far entirely conjectural (not even to the stage of being vaporware) so I think it's highly premature to plan for them at this point.) -- David A. Holland dholl...@netbsd.org
Re: Path to kernel modules (second attempt)
On 07.07.2012 21:57, Mindaugas Rasiukevicius wrote: > Hello, > > Regarding the PR/38724, I propose to change the path to "/kernel/". > Can we reach some consensus quickly for netbsd-6? /kernel is way to close to /kern, and they serve different purposes. IMHO that will raise confusion. Technically modules are not libraries, but maybe /libdata/module is a good option? We already have firmwares in /libdata/firmware, and those get used by the kernel. -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: Path to kernel modules (second attempt)
On Sat, Jul 07, 2012 at 08:57:10PM +0100, Mindaugas Rasiukevicius wrote: > Regarding the PR/38724, I propose to change the path to "/kernel/". > Can we reach some consensus quickly for netbsd-6? I'd vote for "/lib/modules" noted in the PR (or maybe under /libdata?) simply because in my opinion the root hierarchy has already been abused too much in NetBSD. On the other hand, I don't see anything wrong with /stand either. Two cents, - Jukka.
Path to kernel modules (second attempt)
Hello, Regarding the PR/38724, I propose to change the path to "/kernel/". Can we reach some consensus quickly for netbsd-6? Thanks. -- Mindaugas
