hi,
> Hello,
>
> 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 k
On Mon, Aug 01, 2011 at 09:00:36PM +, David Holland wrote:
> > Not withstanding dh's comment, why not pass in all the namei flags.
> >
> > > + error = namei_simple_user(path, flags, &vp);
>
> Because I gimmicked up the flags for namei_simple specifically to
> disallow that sort
On Mon, Aug 01, 2011 at 09:31:11PM +0100, David Laight wrote:
> > + if (flags & FOLLOW)
> > + namei_simple_flags = NSM_FOLLOW_TRYEMULROOT;
> > + else
> > + namei_simple_flags = NSM_NOFOLLOW_TRYEMULROOT;
> > +
> > + error = namei_simple_user(path, namei_simple_flags, &vp)
On Mon, Aug 01, 2011 at 09:46:33AM +, Emmanuel Dreyfus wrote:
> + if (flags & FOLLOW)
> + namei_simple_flags = NSM_FOLLOW_TRYEMULROOT;
> + else
> + namei_simple_flags = NSM_NOFOLLOW_TRYEMULROOT;
> +
> + error = namei_simple_user(path, namei_simple_flags, &vp
Christos Zoulas wrote:
> Except for the ktruser() call, looks good to me (my personal opinion).
Um, yes, that one was another pending patch I had for later. For now
ktrace does not show symlink(2) targets, which is annoying: sometime
you cannot tell what is going on.
--
Emmanuel Dreyfus
http:
On Mon, Aug 01, 2011 at 08:59:57PM +0200, Matthias Drochner wrote:
>
> I think it is OK to attach the PCI buses which are defined by ACPI
> at acpi. The attachment frontend can install hooks to get interrupt
> routing right. This would also help wakeup support for eg USB
> and ethernet devices.
I
On Mon, Aug 01, 2011 at 04:05:32AM +0200, Emmanuel Dreyfus wrote:
> > You still haven't explained what glusterfs is doing that's so evil or
> > why it can't be fixed by having it copy the symlink when that's the
> > case in question.
>
> glusterfs uses the native filesystem as its storage bac
On Mon, Aug 01, 2011 at 09:46:33AM +, Emmanuel Dreyfus wrote:
> +return do_sys_link(l, path, link, FOLLOW, retval);
>
> +return do_sys_link(l, path, link, NOFOLLOW, retval);
Can you use a boolean argument for that instead of namei flags?
> +.Fn llink
> +is like
> +.Fn link
> +
bou...@antioche.eu.org said:
> To me it's not clear if it's the way to go (and I guess we'd need a
> pci@pcibios as well ...
I think the pcibios gives so little value that it doesn't deserve
an extra attachment. ACPI is another league - it is essential
for interrupt routing and power management.
In article <20110801094633.ga17...@homeworld.netbsd.org>,
Emmanuel Dreyfus wrote:
>-=-=-=-=-=-
>
>On Sun, Jul 31, 2011 at 06:36:53PM +, Christos Zoulas wrote:
>> I don't have an issue with it as long as:
>> - fsck does not get confused
>> - filesystems don't need to be modified to s
On Mon, Aug 01, 2011 at 07:33:27PM +0200, Matthias Drochner wrote:
>
> bou...@antioche.eu.org said:
> > up to now, device_properties() has been used to pass informations
> > which doesn't comes directly from the parent (as opposed to the attach
> > structure)
>
> If we allow to attach pci at acpi
bou...@antioche.eu.org said:
> up to now, device_properties() has been used to pass informations
> which doesn't comes directly from the parent (as opposed to the attach
> structure)
If we allow to attach pci at acpi, the information would come
directly from the parent. It is not only address spa
> I would try to unplung/replug the drive.
I already did that.
> I would also look at SMART datas (using the smartmontool package, atactl from
> 4.0 won't report all details).
OK, I'll re-attach the drive to another machine. I already did attach it to a
desktop machine to check it does spin up (y
On Mon, Aug 01, 2011 at 02:18:36PM +0200, Edgar Fuß wrote:
> > But if you plugged the new drive in the same slot as the old
> > one, you should be able to use it without extra steps.
> In the meantime, I figured out that the supposedly failed drive is OK.
> There seems to be something wrong with th
> drvctl should work for you - this was added in the last couple of
> months.
The server in question is on 4.0.1.
drvctl should work for you - this was added in the last couple of
months.
On Mon, 1 Aug 2011, Manuel Bouyer wrote:
On Mon, Aug 01, 2011 at 12:43:03PM +0200, Edgar Fuß wrote:
I've got a hot-pluggable SATA drive in a RAID1 that failed.
I've never been into this with SATA, only with SCA.
What do
> But if you plugged the new drive in the same slot as the old
> one, you should be able to use it without extra steps.
In the meantime, I figured out that the supposedly failed drive is OK.
There seems to be something wrong with the SATA channel it was attached to:
[...]
svwsata0 at pci1 dev 14 f
On Mon, Aug 01, 2011 at 12:43:03PM +0200, Edgar Fuß wrote:
> I've got a hot-pluggable SATA drive in a RAID1 that failed.
> I've never been into this with SATA, only with SCA.
> What do I do after physically replacing the drive to make the new one known
> to the kernel?
> I do know how to re-build
On Mon 01 Aug 2011 at 12:09:34 +0200, Joerg Sonnenberger wrote:
> You are adding a lot of complexity to workaround portability issues of a
> single application. Let's start the other way -- has FreeBSD added
> llink(2)? What about OSX? Solaris?
FreeBSD 8 has ln -P. From the manual, it seems that t
I've got a hot-pluggable SATA drive in a RAID1 that failed.
I've never been into this with SATA, only with SCA.
What do I do after physically replacing the drive to make the new one known to
the kernel?
I do know how to re-build the RAID, but what's the analogous to scsictl
detach/scan?
Rhialto wrote:
> LN(1) FreeBSD General Commands Manual LN(1)
(...)
> -PWhen creating a hard link to a symbolic link, create a hard link to
>the symbolic link itself. This option cancels the -L option.
I can add this this to NetBSD as well
On Mon 01 Aug 2011 at 10:50:50 +0200, Matthias Drochner wrote:
> While the "DESCRIPTION" chapter doesn't tell it explicitely,
> we have the following in "ERRORS":
>
> [ELOOP]
> A loop exists in symbolic links encountered during resolution of the path1
> or path2 argument.
>
> This implies that
Joerg Sonnenberger wrote:
> > You did not explain what problems it would introduce, did you?
> You are adding a lot of complexity to workaround portability issues of a
> single application.
It is not that complex. See the patch I posted this morning, the thing
is really simple, and it works qui
On Mon, Aug 01, 2011 at 04:05:33AM +0200, Emmanuel Dreyfus wrote:
> Joerg Sonnenberger wrote:
>
> > Given the very small number of programs that manage to mess up the
> > symlink usage, I'm kind of opposed to providing another system call just
> > as work around for them.
>
> You did not explain
On Mon, Aug 01, 2011 at 11:30:31AM +0200, Matthias Drochner wrote:
>
> bou...@antioche.eu.org said:
> > device_properties() uses property lists, so I think poplists is right
> > for your usage too. It looks like it's a property of a bus node and I
> > can't see why it should be different from a de
On Sun, Jul 31, 2011 at 06:36:53PM +, Christos Zoulas wrote:
> I don't have an issue with it as long as:
> - fsck does not get confused
> - filesystems don't need to be modified to support it
> - there is consensus that this is not harmful
> - I am also ambivalent about
bou...@antioche.eu.org said:
> device_properties() uses property lists, so I think poplists is right
> for your usage too. It looks like it's a property of a bus node and I
> can't see why it should be different from a device node. It should
> probably be in the device property of the bus node's d
m...@netbsd.org said:
> Both behaviors are standard compliant, since SUSv2 says nothing about
> resolving symlinks or not.
While the "DESCRIPTION" chapter doesn't tell it explicitely,
we have the following in "ERRORS":
[ELOOP]
A loop exists in symbolic links encountered during resolution of the
28 matches
Mail list logo
