i like the current method. it is how pretty much all other
systems i'm familiar with work, too.
.mrg.
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
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
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 whi
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
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-
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 do
-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 system
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:
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?
>
>pa
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
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.
>
>
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
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,
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 r
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 a
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 th
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 ever
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
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 brea
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
> 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!
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 sy
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
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 chan
25 matches
Mail list logo
