re: Don't load kernel modules from the current directory
i like the current method. it is how pretty much all other systems i'm familiar with work, too. .mrg.
Don't load kernel modules from the current directory
modload looks for modules first in the current working directory, if not
found there the system module area is searched (/stand/...).
otoh, we don't look in '.' when we load libraries in userspace programs,
we even removed '.' from the Lua loader but when it comes to kernel code
we happily accept anything that sits there "by accident".
The proposed and attached patch changes this in two ways: The module
loader never looks in '.' by always constructing a path pointing to the
system module area and the function kobj_load_vfs() ensures the path
starts with a '/', thus it will only work with absolute paths.
The consequence is that kernel modules can only be loaded via the module
loader interface from /stand///.kmod and that
generally only objects with absolute paths can be loaded using
kobj_load_vfs().
Comments?
Index: sys/kern/kern_module_vfs.c
===
RCS file: /cvsroot/src/sys/kern/kern_module_vfs.c,v
retrieving revision 1.10
diff -u -r1.10 kern_module_vfs.c
--- sys/kern/kern_module_vfs.c 28 Nov 2010 00:26:38 - 1.10
+++ sys/kern/kern_module_vfs.c 3 Aug 2011 06:26:56 -
@@ -76,17 +76,9 @@
*filedictp = NULL;
path = PNBUF_GET();
- if (!autoload) {
- nochroot = false;
- snprintf(path, MAXPATHLEN, "%s", name);
- error = kobj_load_vfs(&mod->mod_kobj, path, nochroot);
- }
- if (autoload || (error == ENOENT)) {
- nochroot = true;
- snprintf(path, MAXPATHLEN, "%s/%s/%s.kmod",
- module_base, name, name);
- error = kobj_load_vfs(&mod->mod_kobj, path, nochroot);
- }
+ nochroot = true;
+ snprintf(path, MAXPATHLEN, "%s/%s/%s.kmod", module_base, name, name);
+ error = kobj_load_vfs(&mod->mod_kobj, path, nochroot);
if (error != 0) {
PNBUF_PUT(path);
if (autoload) {
Index: sys/kern/subr_kobj_vfs.c
===
RCS file: /cvsroot/src/sys/kern/subr_kobj_vfs.c,v
retrieving revision 1.4
diff -u -r1.4 subr_kobj_vfs.c
--- sys/kern/subr_kobj_vfs.c19 Nov 2010 06:44:43 - 1.4
+++ sys/kern/subr_kobj_vfs.c3 Aug 2011 06:26:56 -
@@ -139,6 +139,10 @@
int error;
kobj_t ko;
+ KASSERT(path != NULL);
+ if (*path != '/')
+ return ENOENT;
+
cred = kauth_cred_get();
ko = kmem_zalloc(sizeof(*ko), KM_SLEEP);
Index: sbin/modload/modload.8
===
RCS file: /cvsroot/src/sbin/modload/modload.8,v
retrieving revision 1.40
diff -u -r1.40 modload.8
--- sbin/modload/modload.8 14 Dec 2010 16:23:59 - 1.40
+++ sbin/modload/modload.8 3 Aug 2011 06:26:57 -
@@ -32,7 +32,7 @@
.\"
.\" <>
.\"
-.Dd December 14, 2010
+.Dd August 3, 2011
.Dt MODLOAD 8
.Os
.Sh NAME
@@ -59,8 +59,7 @@
.Ar module
paramamter into the running system.
.Pp
-The current working directory is first searched for the module object file.
-If not found there, the default system module areas are searched.
+Modules are loaded from the default system module areas.
.Pp
The options to
.Nm
Re: genfs_getpages vs. genfs_compat_getpages
On Tue, Aug 02, 2011 at 02:19:38PM -0500, paul_kon...@dell.com wrote: > Thanks, that helps. It makes me wonder why NTFS uses it. Not > quite such a surprise that LFS uses it... LFS doesn't... -- David A. Holland dholl...@netbsd.org
Re: kcpuset(9) interface
hi,
> y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
>> > Here is a reworked dynamic CPU set implementation for kernel (shared
>> > cpuset.c in src/common will be moved to libc) - a kcpuset(9) interface:
>> >
>> > http://www.netbsd.org/~rmind/kcpuset_ng.diff
>> >
>> > It supports early use while the system is cold through a fix up
>> > mechanism, see kcpuset_sysinit(). That would enable us to use kcpuset
>> > (9) in MD code, such as pmap(9). The intention of interface is to: 1)
>> > replace hard-coded parts (e.g. limited to uint32_t or MAXCPUS constant)
>> > with a more dynamic mechanism 2) replace and unify duplicated CPU
>> > bitset code (e.g. in MIPS, PowerPC, sparc64, which have own copies).
>>
>> thanks for working on this.
>> and sorry for commenting only on a minor point.
>
> Your comments are always welcome. :)
>
>> why did you change kcpuset_t to a pointer from a structure?
>> i always feel awkward to compare an opaque type with NULL.
>
> The reason is that kcpuset_t now points directly to the bit field rather
> than opaque struct kcpuset_impl. Do you prefer wrapping, e.g. like this:
>
> struct kcpuset { uint32_t bitfield[0]; };
>
> Except this is not C99..
is it necessary to expose the fact that it's an array to the API users?
if it isn't, a dummy structure tag should just work.
btw, on second thought, i think it might be worth to allow kcpuset_t be
just a scalar type and avoid dynamic allocations for ports which can't
have large MAXCPUS. in that case, we should somehow abstract NULL
comparisons.
YAMAMOTO Takashi
>
> --
> Mindaugas
Re: kcpuset(9) interface
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> > Here is a reworked dynamic CPU set implementation for kernel (shared
> > cpuset.c in src/common will be moved to libc) - a kcpuset(9) interface:
> >
> > http://www.netbsd.org/~rmind/kcpuset_ng.diff
> >
> > It supports early use while the system is cold through a fix up
> > mechanism, see kcpuset_sysinit(). That would enable us to use kcpuset
> > (9) in MD code, such as pmap(9). The intention of interface is to: 1)
> > replace hard-coded parts (e.g. limited to uint32_t or MAXCPUS constant)
> > with a more dynamic mechanism 2) replace and unify duplicated CPU
> > bitset code (e.g. in MIPS, PowerPC, sparc64, which have own copies).
>
> thanks for working on this.
> and sorry for commenting only on a minor point.
Your comments are always welcome. :)
> why did you change kcpuset_t to a pointer from a structure?
> i always feel awkward to compare an opaque type with NULL.
The reason is that kcpuset_t now points directly to the bit field rather
than opaque struct kcpuset_impl. Do you prefer wrapping, e.g. like this:
struct kcpuset { uint32_t bitfield[0]; };
Except this is not C99..
--
Mindaugas
Re: linkat(2)
Emmanuel Dreyfus wrote: > But that does not answer the original question: it is sane to > ifdef _NETBSD_SOURCE a partial implementation of linkat(), while the > full thing is not yet ready. I can answer to myself: through config.h -> float.h -> whatever, _NETBSD_SOURCE gets defined in /usr/src-20110608/external/gpl2/xcvs/dist/lib/chdir-long.c -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: Adding linux_link(2) system call, second round
David Holland wrote: > > It is much more code, since it happens on the client, which sends > > filesystem operations to lower layers and regain control later using > > callbacks. Have a look to the sources (xlator/cluster/dht/dht-rename.c) > > and you will see why it is complex. > > Where does that path live? glusterfs source? Yes, get it from here: http://download.gluster.com/pub/gluster/glusterfs/3.2/3.2.2/ glusterfs-3.2.2.tar.gz -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
RE: genfs_getpages vs. genfs_compat_getpages
-Original Message- From: Eduardo Horvath [mailto:e...@netbsd.org] Sent: Tuesday, August 02, 2011 2:41 PM To: Koning, Paul Cc: tech-kern@netbsd.org Subject: Re: genfs_getpages vs. genfs_compat_getpages On Tue, 2 Aug 2011, paul_kon...@dell.com wrote: > Gentlepeople, > > Some file systems use genfs_compat_getpages while others (most of them) use > genfs_getpages. I'm trying to figure out the essential differences, and why > one would pick one over the other. > > Any pointers? genfs_vnops.c: revision 1.43 date: 2001/12/18 07:49:36; author: chs; state: Exp; lines: +137 -2 add some compatibility routines to allow mmap() to work non-UBCified filesystems (in the same non-coherent fashion that they worked before). = Thanks, that helps. It makes me wonder why NTFS uses it. Not quite such a surprise that LFS uses it... paul
Re: genfs_getpages vs. genfs_compat_getpages
On Tue, 2 Aug 2011, paul_kon...@dell.com wrote: > Gentlepeople, > > Some file systems use genfs_compat_getpages while others (most of them) use > genfs_getpages. I'm trying to figure out the essential differences, and why > one would pick one over the other. > > Any pointers? genfs_vnops.c: revision 1.43 date: 2001/12/18 07:49:36; author: chs; state: Exp; lines: +137 -2 add some compatibility routines to allow mmap() to work non-UBCified filesystems (in the same non-coherent fashion that they worked before). = Eduardo
Re: genfs_getpages vs. genfs_compat_getpages
On Tue, 2 Aug 2011 13:08:55 -0500 wrote: > Gentlepeople, > > Some file systems use genfs_compat_getpages while others (most of them) use > genfs_getpages. I'm trying to figure out the essential differences, and why > one would pick one over the other. > > Any pointers? > >paul Without looking I would guess new users shouldnt use the compat version. -- NetBSD - Simplicity is prerequisite for reliability Software Engineering Department, University of Szeged
genfs_getpages vs. genfs_compat_getpages
Gentlepeople, Some file systems use genfs_compat_getpages while others (most of them) use genfs_getpages. I'm trying to figure out the essential differences, and why one would pick one over the other. Any pointers? paul
Re: Adding linux_link(2) system call, second round
On Tue, Aug 02, 2011 at 04:34:12PM +, Emmanuel Dreyfus wrote: > > As opposed to link/unlink? I still don't see why this would be more > > than a half-dozen lines of code, if that. By your previous > > descriptions it already needs to stat the object to check if it's a > > directory. > > It is much more code, since it happens on the client, which sends > filesystem operations to lower layers and regain control later using > callbacks. Have a look to the sources (xlator/cluster/dht/dht-rename.c) > and you will see why it is complex. Where does that path live? glusterfs source? -- David A. Holland dholl...@netbsd.org
Re: linkat(2)
On Tue, Aug 02, 2011 at 04:27:12PM +, David Holland wrote: > > Does that mean AT_FDCW should be guarded by #ifdef _NETBSD_SOURCE > > until the whole Extended API Set Part 2 is implemented? > > There's a preexisting patch set for *at somewhere. It got rejected in > its original form because it did horrible things instead of > interfacing semi-sanely to namei. But that does not answer the original question: it is sane to ifdef _NETBSD_SOURCE a partial implementation of linkat(), while the full thing is not yet ready. -- Emmanuel Dreyfus m...@netbsd.org
Re: Adding linux_link(2) system call, second round
On Tue, Aug 02, 2011 at 04:30:15PM +, David Holland wrote: > As opposed to link/unlink? I still don't see why this would be more > than a half-dozen lines of code, if that. By your previous > descriptions it already needs to stat the object to check if it's a > directory. It is much more code, since it happens on the client, which sends filesystem operations to lower layers and regain control later using callbacks. Have a look to the sources (xlator/cluster/dht/dht-rename.c) and you will see why it is complex. -- Emmanuel Dreyfus m...@netbsd.org
Re: Adding linux_link(2) system call, second round
On Tue, Aug 02, 2011 at 08:52:56AM +, Emmanuel Dreyfus wrote: > > Sure. But what does it actually do, such that if you have a symlink it > > doesn't work to copy the symlink instead of hardlink it? > > That would probably work for symlinks, since they cannot be updated. > But this would requires heavy changes in the way the code is written. > Basically a rename on a symlink would become a readlink/symlink/unlink. As opposed to link/unlink? I still don't see why this would be more than a half-dozen lines of code, if that. By your previous descriptions it already needs to stat the object to check if it's a directory. -- David A. Holland dholl...@netbsd.org
Re: linkat(2)
On Tue, Aug 02, 2011 at 03:19:58PM +, Emmanuel Dreyfus wrote: > I am about adding linkat(2), which is defined in > The Open Group Technical Standard, 2006, Extended API Set Part 2. > However, I am not going to implement the whole Extended API Set Part 2, > at least for now. This means I am going ot have linkat(2) but not > openat(2) for instance. > > That approach breaks our own build, because > external/gpl2/xcvs/dist/lib/openat.h tests for AT_FDCW, which I defined > for in linkat(2). Then it ssumes it means openat(2) is available. > > Does that mean AT_FDCW should be guarded by #ifdef _NETBSD_SOURCE > until the whole Extended API Set Part 2 is implemented? There's a preexisting patch set for *at somewhere. It got rejected in its original form because it did horrible things instead of interfacing semi-sanely to namei. The necessary namei parts should be tractable nowadays; however, I probably can't get to it before this weekend, and it'll take just as long to explain what to do as to do it myself... -- David A. Holland dholl...@netbsd.org
Re: Adding linux_link(2) system call, second round
On Tue, Aug 02, 2011 at 05:45:56PM +0200, Rhialto wrote: > Ok, then we also want openat(2), fchmodat(2) (which seems to be misnamed > and looks more like a chmodat(2)), unlinkat(2), fchownat(2) (same remark > as fchmodat), etc. And you forgot fexecve(). I agree we want all of them, but I do not think we want everything at once. We have linkat(2) which fixes the problem of hard linking symlinks. This is a small and harmless change. And we have these "*at" functions that allow specifying pathnames relative to a directory specified by a file descriptor. That means modifying the namei interface, not a challenge, but something a bit more intrusive. Therefore I would like to go incremental, by first supproting this: linkat (AT_FDCW, name1, AT_FDCW, name2, 0) linkat (AT_FDCW, name1, AT_FDCW, name2, AT_SYMLINK_FOLLOW) and return ENOSYS if fd1 and fd2 have values other than AT_FDCW. Then do the full Extended API set 2. -- Emmanuel Dreyfus m...@netbsd.org
Re: Adding linux_link(2) system call, second round
On Tue 02 Aug 2011 at 09:05:27 +, Emmanuel Dreyfus wrote: > On Tue, Aug 02, 2011 at 10:02:39AM +0100, Roland C. Dowdeswell wrote: > > It looks like linkat(2) is POSIX.1-2008 and is implemented by Linux > > as well as FreeBSD. It might be the more portable direction to go. > > Right, then everything is simple, this is just the matter of > implementing a standard system call. Ok, then we also want openat(2), fchmodat(2) (which seems to be misnamed and looks more like a chmodat(2)), unlinkat(2), fchownat(2) (same remark as fchmodat), etc. openat(2) is similar to, but not the same as, the existing function fhopen(2). These functions can be found here too: http://pubs.opengroup.org/onlinepubs/9699919799/functions/.html FreeBSD seems to have: faccessat fchmodat fchownat fstatat futimesat linkat mkdirat mkfifoat mknodat openat readlinkat renameat symlinkat unlinkat -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: SATA: lost interrupt/reset failed
hello. On a NetBSD-4.x system, I know of no way to re-enable the SATA port short of rebooting. Once rebooted, of course, you'll be able to rebuild your raid and start counting those uptime days again. -Brian On Aug 2, 2:53pm, Edgar =?iso-8859-1?B?RnXf?= wrote: } Subject: Re: SATA: lost interrupt/reset failed } > OK, I'll re-attach the drive to another machine. } I did that and the SMART status is OK. } } So, anything short of re-booting the server to unlock the locked up SATA port? I'll be losing 455 days of uptime! >-- End of excerpt from Edgar =?iso-8859-1?B?RnXf?=
linkat(2)
I am about adding linkat(2), which is defined in The Open Group Technical Standard, 2006, Extended API Set Part 2. However, I am not going to implement the whole Extended API Set Part 2, at least for now. This means I am going ot have linkat(2) but not openat(2) for instance. That approach breaks our own build, because external/gpl2/xcvs/dist/lib/openat.h tests for AT_FDCW, which I defined for in linkat(2). Then it ssumes it means openat(2) is available. Does that mean AT_FDCW should be guarded by #ifdef _NETBSD_SOURCE until the whole Extended API Set Part 2 is implemented? -- Emmanuel Dreyfus m...@netbsd.org
Re: SATA: lost interrupt/reset failed
On Tue, Aug 02, 2011 at 02:53:11PM +0200, Edgar Fuß wrote: > > OK, I'll re-attach the drive to another machine. > I did that and the SMART status is OK. > > So, anything short of re-booting the server to unlock the locked up SATA > port? I'll be losing 455 days of uptime! I'd see if it reacts to reset again after replugging in the initial slot. If it does not, I fear a reboot in required. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: SATA: lost interrupt/reset failed
> OK, I'll re-attach the drive to another machine. I did that and the SMART status is OK. So, anything short of re-booting the server to unlock the locked up SATA port? I'll be losing 455 days of uptime!
Re: Adding linux_link(2) system call, second round
On Tue, Aug 02, 2011 at 10:02:39AM +0100, Roland C. Dowdeswell wrote: > It looks like linkat(2) is POSIX.1-2008 and is implemented by Linux > as well as FreeBSD. It might be the more portable direction to go. Right, then everything is simple, this is just the matter of implementing a standard system call. Here is the specification. I will change llink to linkat and commit shortly. http://pubs.opengroup.org/onlinepubs/9699919799/functions/link.html -- Emmanuel Dreyfus m...@netbsd.org
Re: Adding linux_link(2) system call, second round
On Tue, Aug 02, 2011 at 08:52:56AM +, Emmanuel Dreyfus wrote: > > On Mon, Aug 01, 2011 at 07:20:30PM +, David Holland wrote: > > Sure. But what does it actually do, such that if you have a symlink it > > doesn't work to copy the symlink instead of hardlink it? > > That would probably work for symlinks, since they cannot be updated. > But this would requires heavy changes in the way the code is written. > Basically a rename on a symlink would become a readlink/symlink/unlink. > This is not really a portability patch, it is a code rewrite which would > consume more time than I can afford here. I suspect glusterfs developpers > will have to do it if they want to support something else than Linux, but > I have no idea when, therefore it is not wise to hold our breath on it. > > llink(2) is a simple change, FreeBSD already went there with linkat(2), > and it makes everything simple. It looks like linkat(2) is POSIX.1-2008 and is implemented by Linux as well as FreeBSD. It might be the more portable direction to go. -- Roland Dowdeswell http://Imrryr.ORG/~elric/
Re: Adding linux_link(2) system call, second round
On Mon, Aug 01, 2011 at 07:20:30PM +, David Holland wrote: > Sure. But what does it actually do, such that if you have a symlink it > doesn't work to copy the symlink instead of hardlink it? That would probably work for symlinks, since they cannot be updated. But this would requires heavy changes in the way the code is written. Basically a rename on a symlink would become a readlink/symlink/unlink. This is not really a portability patch, it is a code rewrite which would consume more time than I can afford here. I suspect glusterfs developpers will have to do it if they want to support something else than Linux, but I have no idea when, therefore it is not wise to hold our breath on it. llink(2) is a simple change, FreeBSD already went there with linkat(2), and it makes everything simple. -- Emmanuel Dreyfus m...@netbsd.org
