Re: Adding linux_link(2) system call, second round
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 path1 or path2 argument. This implies that the intention is that symlinks are followed. el...@imrryr.org said: Or perhaps llink(2) for symmetry with lchmod(2) and lstat(2). This looks reasonable. best regards Matthias Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
[PATCH] llink(2) (was: Re: Adding linux_link(2) system call, second round)
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 exposing this in the native abi
because it will only cause confusion.
Attached is the patch that adds llink(2) and its documentation. The test I
ran are below (the llink program just calls llink(2)).
fsck has no probmem with it, ffs was not modified. For it
being harmful, I cannot immagine what could be done with it, but
we could restrict it to root just in case.
On confusion, well, I think the llink name speaks by itself.
# ls -li
total 1
3648 drwxr-xr-x 2 root wheel 512 Aug 1 11:31 dir
3 -rw-r--r-- 2 root wheel0 Aug 1 11:30 file
3 -rw-r--r-- 2 root wheel0 Aug 1 11:30 hfile
5 lrwxr-xr-x 1 root wheel3 Aug 1 11:31 sdir - dir
4 lrwxr-xr-x 1 root wheel4 Aug 1 11:31 sfile - file
6 lrwxr-xr-x 1 root wheel 11 Aug 1 11:32 void - nonexistent
# /home2/manu/llink sfile hsfile
# /home2/manu/llink sdir hsdir
# /home2/manu/llink void hvoid
# ls -li
total 1
3648 drwxr-xr-x 2 root wheel 512 Aug 1 11:31 dir
3 -rw-r--r-- 2 root wheel0 Aug 1 11:30 file
3 -rw-r--r-- 2 root wheel0 Aug 1 11:30 hfile
5 lrwxr-xr-x 2 root wheel3 Aug 1 11:31 hsdir - dir
4 lrwxr-xr-x 2 root wheel4 Aug 1 11:31 hsfile - file
6 lrwxr-xr-x 2 root wheel 11 Aug 1 11:32 hvoid - nonexistent
5 lrwxr-xr-x 2 root wheel3 Aug 1 11:31 sdir - dir
4 lrwxr-xr-x 2 root wheel4 Aug 1 11:31 sfile - file
6 lrwxr-xr-x 2 root wheel 11 Aug 1 11:32 void - nonexistent
--
Emmanuel Dreyfus
m...@netbsd.org
Index: include/unistd.h
===
RCS file: /cvsroot/src/include/unistd.h,v
retrieving revision 1.126
diff -U4 -r1.126 unistd.h
--- include/unistd.h26 Jun 2011 16:42:40 - 1.126
+++ include/unistd.h1 Aug 2011 09:34:20 -
@@ -124,8 +124,9 @@
pid_t getppid(void);
uid_t getuid(void);
int isatty(int);
int link(const char *, const char *);
+int llink(const char *, const char *);
longpathconf(const char *, int);
int pause(void);
int pipe(int *);
#if __SSP_FORTIFY_LEVEL == 0
Index: sys/kern/vfs_syscalls.c
===
RCS file: /cvsroot/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.430
diff -U4 -r1.430 vfs_syscalls.c
--- sys/kern/vfs_syscalls.c 17 Jun 2011 14:23:51 - 1.430
+++ sys/kern/vfs_syscalls.c 1 Aug 2011 09:34:20 -
@@ -1769,27 +1769,32 @@
}
/*
* Make a hard file link.
+ * The flag argument can be
+ * - FOLLOW for sys_link, to link to symlink target
+ * - NOFOLLOW for sys_llink, to link to symlink itself
*/
/* ARGSUSED */
-int
-sys_link(struct lwp *l, const struct sys_link_args *uap, register_t *retval)
+static int
+do_sys_link(struct lwp *l, const char *path, const char *link,
+ int flags, register_t *retval)
{
- /* {
- syscallarg(const char *) path;
- syscallarg(const char *) link;
- } */
struct vnode *vp;
struct pathbuf *linkpb;
struct nameidata nd;
+ namei_simple_flags_t namei_simple_flags;
int error;
- error = namei_simple_user(SCARG(uap, path),
- NSM_FOLLOW_TRYEMULROOT, vp);
+ 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);
if (error != 0)
return (error);
- error = pathbuf_copyin(SCARG(uap, link), linkpb);
+ error = pathbuf_copyin(link, linkpb);
if (error) {
goto out1;
}
NDINIT(nd, CREATE, LOCKPARENT | TRYEMULROOT, linkpb);
@@ -1826,8 +1831,35 @@
goto out2;
}
int
+sys_link(struct lwp *l, const struct sys_link_args *uap, register_t *retval)
+{
+ /* {
+ syscallarg(const char *) path;
+ syscallarg(const char *) link;
+ } */
+ const char *path = SCARG(uap, path);
+ const char *link = SCARG(uap, link);
+
+ return do_sys_link(l, path, link, FOLLOW, retval);
+}
+
+int
+sys_llink(struct lwp *l, const struct sys_llink_args *uap, register_t *retval)
+{
+ /* {
+ syscallarg(const char *) path;
+ syscallarg(const char *) link;
+ } */
+ const char *path = SCARG(uap, path);
+ const char *link = SCARG(uap, link);
+
+ return do_sys_link(l, path, link, NOFOLLOW, retval);
+}
+
+
+int
do_sys_symlink(const char *patharg, const char *link, enum uio_seg seg)
{
struct proc *p = curproc;
struct vattr vattr;
@@ -1850,8 +1882,10 @@
Re: pchb@acpi
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 device node. It should probably be in the device property of the bus node's device_t. I can't follow this logics. Since almost everything in a device's softc is a property of the device, we could stop using C structures completely then... the softc is private to the device (it eventually copies informations passed from the parent, and the attach informations could be properties as well). 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), and possibly from different place, and may possibly not be there. If I understood it properly, we still want to have pchb to attach at pci, but using informations from BIOS or ACPI if available. It looks like this fits device_properties(), much more than and extention of the pci attach args. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: Adding linux_link(2) system call, second round
On Mon, Aug 01, 2011 at 04:05:33AM +0200, Emmanuel Dreyfus wrote: Joerg Sonnenberger jo...@britannica.bec.de 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 what problems it would introduce, did you? 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? Joerg
Re: Adding linux_link(2) system call, second round
Joerg Sonnenberger jo...@britannica.bec.de 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 quite well. Let's start the other way -- has FreeBSD added llink(2)? What about OSX? Solaris? OSX did not in X.5, I do not know for the others. But we do not know if developers of theses systems are aware of this portability problem. We may be the first that got there, it does not means we have to be wrong. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: Adding linux_link(2) system call, second round
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 the intention is that symlinks are followed. Non-final symlinks are always followed, even for lchmod(2), readlink(2) and similar functions, right? For instance, readlink(2)'s man page also mentions ELOOP. Another argument that allowing hard links to symlinks is only natural: The rename(2) operation does it in any case (on ffs). And one *can* rename symlinks. From /usr/src/sys/ufs/ufs/ufs_vnops.c: /* * Rename vnode operation * rename(foo, bar); * is essentially * unlink(bar); * link(foo, bar); * unlink(foo); * but ``atomically''. Can't do full commit without saving state in the * inode on disk which isn't feasible at this time. Best we can do is * always guarantee the target exists. The code below that doesn't appear to special-case symlinks, only directories. FreeBSD also allows hard links to symlinks, with the ln -P option. (This must have been introduced in version 7 or 8; 6.1 doesn't have it but 8.1 does) LN(1) FreeBSD General Commands Manual LN(1) NAME ln, link -- link files SYNOPSIS ln [-L | -P | -s [-F]] [-f | -iw] [-hnv] source_file [target_file] ln [-L | -P | -s [-F]] [-f | -iw] [-hnv] source_file ... target_dir link source_file target_file DESCRIPTION ... -PWhen creating a hard link to a symbolic link, create a hard link to the symbolic link itself. This option cancels the -L option. test$ ln -s foo bar test$ l total 8 drwxr-xr-x 2 olafs vb 3 Aug 1 12:25 ./ drwxr-xr-x 23 olafs vb 29 Aug 1 12:25 ../ lrwxr-xr-x 1 olafs vb 3 Aug 1 12:25 bar@ - foo test$ ln -P bar baz test$ l total 8 drwxr-xr-x 2 olafs vb 4 Aug 1 12:25 ./ drwxr-xr-x 23 olafs vb 29 Aug 1 12:25 ../ lrwxr-xr-x 2 olafs vb 3 Aug 1 12:25 bar@ - foo lrwxr-xr-x 2 olafs vb 3 Aug 1 12:25 baz@ - foo I tested both on ffs and zfs. The results are the same. -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: Adding linux_link(2) system call, second round
Rhialto rhia...@falu.nl 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 if it is considered desirable. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
SATA: lost interrupt/reset failed (was: scsictl equivalent for SATA)
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 function 0 svwsata0: ServerWorks HT-1000 SATA Controller (rev. 0x00) : DMA svwsata0: using ioapic0 pin 11 (irq 11) for native-PCI interrupt svwsata0: primary channel wired to native-PCI mode atabus0 at svwsata0 channel 0 [...] svwsata0 port 0: device present, speed: 1.5Gb/s [...] wd0 at atabus0 drive 0: ST3250310NS wd0: quirks 2FORCE_LBA48 wd0: drive supports 16-sector PIO transfers, LBA48 addressing wd0: 232 GB, 484521 cyl, 16 head, 63 sec, 512 bytes/sect x 488397168 sectors wd0: 32-bit data port wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) wd0(svwsata0:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA) svwsata0 port 1: PHY offline [...] svwsata0:0:0: lost interrupt type: ata tc_bcount: 16384 tc_skip: 0 svwsata0:0:0: bus-master DMA error: missing interrupt, status=0x21 svwsata0:0:0: device timeout, c_bcount=16384, c_skip0 wd0a: device timeout writing fsbn 61002880 of 61002880-61002911 (wd0 bn 61002943; cn 60518 tn 12 sn 43), retrying svwsata0 channel 0: reset failed for drive 0 Also ``atactl /dev/atabus0 reset'' also resulted in ``reset failed''. How do I fix this short of re-booting the machine?
Re: scsictl equivalent for SATA
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 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? There is none at this time (unless something changed recently I didn't notice). 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. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference -- !DSPAM:4e3696682351153699719! - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: scsictl equivalent for SATA
drvctl should work for you - this was added in the last couple of months. The server in question is on 4.0.1.
Re: SATA: lost interrupt/reset failed (was: scsictl equivalent for SATA)
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 the SATA channel it was attached to: [...] svwsata0 at pci1 dev 14 function 0 svwsata0: ServerWorks HT-1000 SATA Controller (rev. 0x00) : DMA svwsata0: using ioapic0 pin 11 (irq 11) for native-PCI interrupt svwsata0: primary channel wired to native-PCI mode atabus0 at svwsata0 channel 0 [...] svwsata0 port 0: device present, speed: 1.5Gb/s [...] wd0 at atabus0 drive 0: ST3250310NS wd0: quirks 2FORCE_LBA48 wd0: drive supports 16-sector PIO transfers, LBA48 addressing wd0: 232 GB, 484521 cyl, 16 head, 63 sec, 512 bytes/sect x 488397168 sectors wd0: 32-bit data port wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) wd0(svwsata0:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA) svwsata0 port 1: PHY offline [...] svwsata0:0:0: lost interrupt type: ata tc_bcount: 16384 tc_skip: 0 svwsata0:0:0: bus-master DMA error: missing interrupt, status=0x21 svwsata0:0:0: device timeout, c_bcount=16384, c_skip0 wd0a: device timeout writing fsbn 61002880 of 61002880-61002911 (wd0 bn 61002943; cn 60518 tn 12 sn 43), retrying svwsata0 channel 0: reset failed for drive 0 Also ``atactl /dev/atabus0 reset'' also resulted in ``reset failed''. How do I fix this short of re-booting the machine? I would try to unplung/replug the drive. I would also look at SMART datas (using the smartmontool package, atactl from 4.0 won't report all details). -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: SATA: lost interrupt/reset failed
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 (you can't tell in the server room because of the ambient noise) and it started to boot.
Re: pchb@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 space usage but also interrupt routing and power management. It looks like this fits device_properties(), much more than and extention of the pci attach args. It would not be the pci attach args. That's the power of multiple frontends that we can have special attach args, the softc extended as needed and the extra code in its own source file which gets only compiled if the kernel is configured that way. With properties, you would have all that nasty parsing code in the common sources. And no compile time type checks. best regards Matthias Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Re: pchb@acpi
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, the information would come directly from the parent. It is not only address space usage but also interrupt routing and power management. It looks like this fits device_properties(), much more than and extention of the pci attach args. It would not be the pci attach args. That's the power of multiple frontends that we can have special attach args, the softc extended as needed and the extra code in its own source file which gets only compiled if the kernel is configured that way. With properties, you would have all that nasty parsing code in the common sources. And no compile time type checks. this is true, if we attach it at acpi instead of pci. To me it's not clear if it's the way to go (and I guess we'd need a pci@pcibios as well ...). It has been argued before that attachement at apci should go away, and use apci to drive the isa autoconf instead ... -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: [PATCH] llink(2) (was: Re: Adding linux_link(2) system call, second round)
In article 20110801094633.ga17...@homeworld.netbsd.org, Emmanuel Dreyfus m...@netbsd.org 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 support it - there is consensus that this is not harmful - I am also ambivalent about exposing this in the native abi because it will only cause confusion. Attached is the patch that adds llink(2) and its documentation. The test I ran are below (the llink program just calls llink(2)). fsck has no probmem with it, ffs was not modified. For it being harmful, I cannot immagine what could be done with it, but we could restrict it to root just in case. On confusion, well, I think the llink name speaks by itself. Except for the ktruser() call, looks good to me (my personal opinion). christos
Re: pchb@acpi
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. Without it, you don't get correct interrupt routing on MP systems (unless you resort to MPIs...), and no system-wide power management on x86. It has been argued before that attachement at apci should go away 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. and use apci to drive the isa autoconf instead ... My opinion on this is that we should get chips which are part of the platform (timer/RTC/PICs/npx) out of the isa section, so that one can use a modern PC without any isa bus configured. ACPI's help might or might be useful for that -- at least it would not be needed for a real ISA bus. best regards Matthias Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Re: Adding linux_link(2) system call, second round
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 backend. When you rename a filesytem object in the distributed and replicated setup, they have to make sure it remains accessible by another client during the operation. Directories are all present on all servers and therefore are just treated by a rename(2). Other objects are stored on some server and are reteived using a DHT. When they are renamed, they are treated by a distributed link(2)/rename(2)/unlink(2) algorithm. This breaks on NetBSD when the object is a symlink to a directory or a symlink to a nonexistent target, since you cannot link(2) to such an object. 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? The fix is not traightforward, and require a change in the way glusterfs stores symlinks in its distributed and replicated setup. Why? -- David A. Holland dholl...@netbsd.org
Re: pchb@acpi
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. Indeed. We need this for all PCI buses and devices. That is why hacks like device_is_a() etc. won't do. And as you noted, there is awful lot of ugly duplication because ACPI is already heavily required for x86 interrupt routing. That said, I don't think this kind of attachment is required for the IRQ setup per se (at least not in my branch). - Jukka.
Re: [PATCH] llink(2) (was: Re: Adding linux_link(2) system call, second round)
Christos Zoulas chris...@astron.com 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://hcpnet.free.fr/pubz m...@netbsd.org
Re: [PATCH] llink(2) (was: Re: Adding linux_link(2) system call, second round)
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); Not withstanding dh's comment, why not pass in all the namei flags. + error = namei_simple_user(path, flags, vp); David -- David Laight: da...@l8s.co.uk
Re: [PATCH] llink(2) (was: Re: Adding linux_link(2) system call, second round)
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); 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 of thing :-) -- David A. Holland dholl...@netbsd.org
Re: [PATCH] llink(2) (was: Re: Adding linux_link(2) system call, second round)
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 of thing :-) Er, or rather, you can't use | on them. Just passing them would work, but again, please don't... -- David A. Holland dholl...@netbsd.org
Re: kcpuset(9) interface
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 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. why did you change kcpuset_t to a pointer from a structure? i always feel awkward to compare an opaque type with NULL. YAMAMOTO Takashi Comments? -- Mindaugas
