Re: [PATCH] Code style fix for open_exec
Christoph Hellwig wrote:
On Wed, Oct 03, 2007 at 10:40:25PM -0400, Casey Dahlin wrote:
From d2a6c5d29dc34cfea892124ab72b4eb55d2f8a80 Mon Sep 17 00:00:00 2001
From: Casey Dahlin <[EMAIL PROTECTED]>
Date: Wed, 3 Oct 2007 22:01:49 -0400
Subject: [PATCH] Code style fix for open_exec
Fix a horribly mangled 5 level indent and severe abuse of goto in the
open_exec
function.
While the function is not nice your version makes it even worse.
Ouch :) I don't think I did so bad.
Try this one instead which has been in my pending testing tree for a while:
Pretty much all of the stylistic changes were recommended to me already
off list by Joe Perches. I have that in my branch now, and was waiting
on any further feedback before resubmitting. There's a couple of things
here though (particularly the unlikelys) that are worth having. This is
the better code.
Index: linux-2.6/fs/exec.c
===
--- linux-2.6.orig/fs/exec.c2007-09-16 20:29:01.0 +0200
+++ linux-2.6/fs/exec.c 2007-09-16 20:29:56.0 +0200
@@ -669,41 +669,55 @@ EXPORT_SYMBOL(setup_arg_pages);
#endif /* CONFIG_MMU */
+/**
+ * open_exec - open file for execution
+ * @name: filename to open
+ *
+ * Open the file pointed to by @filename in the current namespace
+ * for execution. Error out if the file is not a regular file or
+ * this mount does not allow executing files on it.
+ */
struct file *open_exec(const char *name)
{
struct nameidata nd;
- int err;
struct file *file;
+ int err;
- err = path_lookup_open(AT_FDCWD, name, LOOKUP_FOLLOW, , FMODE_READ|FMODE_EXEC);
- file = ERR_PTR(err);
+ err = path_lookup_open(AT_FDCWD, name, LOOKUP_FOLLOW, ,
+ FMODE_READ|FMODE_EXEC);
+ if (unlikely(err))
+ goto out;
- if (!err) {
- struct inode *inode = nd.dentry->d_inode;
- file = ERR_PTR(-EACCES);
- if (!(nd.mnt->mnt_flags & MNT_NOEXEC) &&
- S_ISREG(inode->i_mode)) {
- int err = vfs_permission(, MAY_EXEC);
- file = ERR_PTR(err);
- if (!err) {
- file = nameidata_to_filp(, O_RDONLY);
- if (!IS_ERR(file)) {
- err = deny_write_access(file);
- if (err) {
- fput(file);
- file = ERR_PTR(err);
- }
- }
-out:
- return file;
- }
- }
- release_open_intent();
- path_release();
+ err = -EACCES;
+ if (unlikely(nd.mnt->mnt_flags & MNT_NOEXEC))
+ goto out_path_release;
+ if (unlikely(!S_ISREG(nd.dentry->d_inode->i_mode)))
+ goto out_path_release;
+
+ err = vfs_permission(, MAY_EXEC);
+ if (unlikely(err))
+ goto out_path_release;
+
+ file = nameidata_to_filp(, O_RDONLY);
+ if (unlikely(IS_ERR(file))) {
+ err = PTR_ERR(file);
+ goto out;
+ }
+
+ err = deny_write_access(file);
+ if (unlikely(err)) {
+ fput(file);
+ goto out;
}
- goto out;
-}
+ return file;
+
+ out_path_release:
+ release_open_intent();
+ path_release();
+ out:
+ return ERR_PTR(err);
+}
EXPORT_SYMBOL(open_exec);
int kernel_read(struct file *file, unsigned long offset,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Code style fix for open_exec
Christoph Hellwig wrote:
On Wed, Oct 03, 2007 at 10:40:25PM -0400, Casey Dahlin wrote:
From d2a6c5d29dc34cfea892124ab72b4eb55d2f8a80 Mon Sep 17 00:00:00 2001
From: Casey Dahlin [EMAIL PROTECTED]
Date: Wed, 3 Oct 2007 22:01:49 -0400
Subject: [PATCH] Code style fix for open_exec
Fix a horribly mangled 5 level indent and severe abuse of goto in the
open_exec
function.
While the function is not nice your version makes it even worse.
Ouch :) I don't think I did so bad.
Try this one instead which has been in my pending testing tree for a while:
Pretty much all of the stylistic changes were recommended to me already
off list by Joe Perches. I have that in my branch now, and was waiting
on any further feedback before resubmitting. There's a couple of things
here though (particularly the unlikelys) that are worth having. This is
the better code.
Index: linux-2.6/fs/exec.c
===
--- linux-2.6.orig/fs/exec.c2007-09-16 20:29:01.0 +0200
+++ linux-2.6/fs/exec.c 2007-09-16 20:29:56.0 +0200
@@ -669,41 +669,55 @@ EXPORT_SYMBOL(setup_arg_pages);
#endif /* CONFIG_MMU */
+/**
+ * open_exec - open file for execution
+ * @name: filename to open
+ *
+ * Open the file pointed to by @filename in the current namespace
+ * for execution. Error out if the file is not a regular file or
+ * this mount does not allow executing files on it.
+ */
struct file *open_exec(const char *name)
{
struct nameidata nd;
- int err;
struct file *file;
+ int err;
- err = path_lookup_open(AT_FDCWD, name, LOOKUP_FOLLOW, nd, FMODE_READ|FMODE_EXEC);
- file = ERR_PTR(err);
+ err = path_lookup_open(AT_FDCWD, name, LOOKUP_FOLLOW, nd,
+ FMODE_READ|FMODE_EXEC);
+ if (unlikely(err))
+ goto out;
- if (!err) {
- struct inode *inode = nd.dentry-d_inode;
- file = ERR_PTR(-EACCES);
- if (!(nd.mnt-mnt_flags MNT_NOEXEC)
- S_ISREG(inode-i_mode)) {
- int err = vfs_permission(nd, MAY_EXEC);
- file = ERR_PTR(err);
- if (!err) {
- file = nameidata_to_filp(nd, O_RDONLY);
- if (!IS_ERR(file)) {
- err = deny_write_access(file);
- if (err) {
- fput(file);
- file = ERR_PTR(err);
- }
- }
-out:
- return file;
- }
- }
- release_open_intent(nd);
- path_release(nd);
+ err = -EACCES;
+ if (unlikely(nd.mnt-mnt_flags MNT_NOEXEC))
+ goto out_path_release;
+ if (unlikely(!S_ISREG(nd.dentry-d_inode-i_mode)))
+ goto out_path_release;
+
+ err = vfs_permission(nd, MAY_EXEC);
+ if (unlikely(err))
+ goto out_path_release;
+
+ file = nameidata_to_filp(nd, O_RDONLY);
+ if (unlikely(IS_ERR(file))) {
+ err = PTR_ERR(file);
+ goto out;
+ }
+
+ err = deny_write_access(file);
+ if (unlikely(err)) {
+ fput(file);
+ goto out;
}
- goto out;
-}
+ return file;
+
+ out_path_release:
+ release_open_intent(nd);
+ path_release(nd);
+ out:
+ return ERR_PTR(err);
+}
EXPORT_SYMBOL(open_exec);
int kernel_read(struct file *file, unsigned long offset,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Network slowdown due to CFS
Ingo Molnar wrote: * Jarek Poplawski <[EMAIL PROTECTED]> wrote: [...] (Btw, in -rc8-mm2 I see new sched_slice() function which seems to return... time.) wrong again. That is a function, not a variable to be cleared. It still gives us a target time, so could we not simply have sched_yield put the thread completely to sleep for the given amount of time? It wholly redefines the operation, and its far more expensive (now there's a whole new timer involved) but it might emulate the expected behavior. Its hideous, but so is sched_yield in the first place, so why not? --CJD - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Code style fix for open_exec
From d2a6c5d29dc34cfea892124ab72b4eb55d2f8a80 Mon Sep 17 00:00:00 2001
From: Casey Dahlin <[EMAIL PROTECTED]>
Date: Wed, 3 Oct 2007 22:01:49 -0400
Subject: [PATCH] Code style fix for open_exec
Fix a horribly mangled 5 level indent and severe abuse of goto in the
open_exec
function.
Signed-off-by: Casey Dahlin <[EMAIL PROTECTED]>
diff --git a/fs/exec.c b/fs/exec.c
index c21a8cc..d73da5a 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -676,32 +676,32 @@ struct file *open_exec(const char *name)
struct file *file;
err = path_lookup_open(AT_FDCWD, name, LOOKUP_FOLLOW, ,
FMODE_READ|FMODE_EXEC);
+
+if (err) return ERR_PTR(err);
+
+file = ERR_PTR(-EACCES);
+if ((nd.mnt->mnt_flags & MNT_NOEXEC) ||
+!S_ISREG(nd.dentry->d_inode->i_mode))
+goto fail;
+
+err = vfs_permission(, MAY_EXEC);
file = ERR_PTR(err);
+if (err) goto fail;
-if (!err) {
-struct inode *inode = nd.dentry->d_inode;
-file = ERR_PTR(-EACCES);
-if (!(nd.mnt->mnt_flags & MNT_NOEXEC) &&
-S_ISREG(inode->i_mode)) {
-int err = vfs_permission(, MAY_EXEC);
-file = ERR_PTR(err);
-if (!err) {
-file = nameidata_to_filp(, O_RDONLY);
-if (!IS_ERR(file)) {
-err = deny_write_access(file);
-if (err) {
-fput(file);
-file = ERR_PTR(err);
-}
-}
-out:
-return file;
-}
-}
-release_open_intent();
-path_release();
+file = nameidata_to_filp(, O_RDONLY);
+if (IS_ERR(file)) return file;
+
+err = deny_write_access(file);
+if (err) {
+fput(file);
+file = ERR_PTR(err);
}
-goto out;
+
+return file;
+fail:
+release_open_intent();
+path_release();
+return file;
}
EXPORT_SYMBOL(open_exec);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Code style fix for open_exec
From d2a6c5d29dc34cfea892124ab72b4eb55d2f8a80 Mon Sep 17 00:00:00 2001
From: Casey Dahlin [EMAIL PROTECTED]
Date: Wed, 3 Oct 2007 22:01:49 -0400
Subject: [PATCH] Code style fix for open_exec
Fix a horribly mangled 5 level indent and severe abuse of goto in the
open_exec
function.
Signed-off-by: Casey Dahlin [EMAIL PROTECTED]
diff --git a/fs/exec.c b/fs/exec.c
index c21a8cc..d73da5a 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -676,32 +676,32 @@ struct file *open_exec(const char *name)
struct file *file;
err = path_lookup_open(AT_FDCWD, name, LOOKUP_FOLLOW, nd,
FMODE_READ|FMODE_EXEC);
+
+if (err) return ERR_PTR(err);
+
+file = ERR_PTR(-EACCES);
+if ((nd.mnt-mnt_flags MNT_NOEXEC) ||
+!S_ISREG(nd.dentry-d_inode-i_mode))
+goto fail;
+
+err = vfs_permission(nd, MAY_EXEC);
file = ERR_PTR(err);
+if (err) goto fail;
-if (!err) {
-struct inode *inode = nd.dentry-d_inode;
-file = ERR_PTR(-EACCES);
-if (!(nd.mnt-mnt_flags MNT_NOEXEC)
-S_ISREG(inode-i_mode)) {
-int err = vfs_permission(nd, MAY_EXEC);
-file = ERR_PTR(err);
-if (!err) {
-file = nameidata_to_filp(nd, O_RDONLY);
-if (!IS_ERR(file)) {
-err = deny_write_access(file);
-if (err) {
-fput(file);
-file = ERR_PTR(err);
-}
-}
-out:
-return file;
-}
-}
-release_open_intent(nd);
-path_release(nd);
+file = nameidata_to_filp(nd, O_RDONLY);
+if (IS_ERR(file)) return file;
+
+err = deny_write_access(file);
+if (err) {
+fput(file);
+file = ERR_PTR(err);
}
-goto out;
+
+return file;
+fail:
+release_open_intent(nd);
+path_release(nd);
+return file;
}
EXPORT_SYMBOL(open_exec);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Network slowdown due to CFS
Ingo Molnar wrote: * Jarek Poplawski [EMAIL PROTECTED] wrote: [...] (Btw, in -rc8-mm2 I see new sched_slice() function which seems to return... time.) wrong again. That is a function, not a variable to be cleared. It still gives us a target time, so could we not simply have sched_yield put the thread completely to sleep for the given amount of time? It wholly redefines the operation, and its far more expensive (now there's a whole new timer involved) but it might emulate the expected behavior. Its hideous, but so is sched_yield in the first place, so why not? --CJD - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Fwd: [BUG:] forcedeth: MCP55 not allowing DHCP]
Apparently I posted this in the middle of an unrelated thread by mistake. If this is the third message you are getting in regard to this issue, sorry :( Just trying to get it in the right place. Original Message Subject:[BUG:] forcedeth: MCP55 not allowing DHCP Date: Tue, 11 Sep 2007 18:05:15 -0400 From: Casey Dahlin <[EMAIL PROTECTED]> To: Linux Kernel I have an Asus Striker Extreme motherboard with two built in MCP55 GigE interfaces. When I build with the original Fedora 7 release kernel ( ftp://ftp.belnet.be/linux/fedora/linux/releases/7/Fedora/i386/os/Fedora/kernel-2.6.21-1.3194.fc7.i686.rpm ) everything works fine. However, when I boot with any updated kernels or any other kernel (have tried building from several points in the linus git tree between 2.6.20 and .23-rc3, and 2.6.21.2 in -stable) I cannot get an IP address via dhcp. There is no error in dmesg. The card shows a link and otherwise appears to be working, but it is as if the dhcp server has been removed from the network. On a running system there is no indication that this is a kernel bug at all, however by varying only the kernel the bug appears and disappears. I've run all these tests repeatedly with no intervening updates of any other packages. As I said I attempted to build 2.6.21.2 ( the point of divergence between the Fedora kernel in question and -stable ) and still the card did not work. I will next attempt to manually build the rpm for the release kernel. If this works I will try experimenting with the included patches to narrow it down, but at this point I'm at a complete loss. -Casey Dahlin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Fwd: [BUG:] forcedeth: MCP55 not allowing DHCP]
Apparently I posted this in the middle of an unrelated thread by mistake. If this is the third message you are getting in regard to this issue, sorry :( Just trying to get it in the right place. Original Message Subject:[BUG:] forcedeth: MCP55 not allowing DHCP Date: Tue, 11 Sep 2007 18:05:15 -0400 From: Casey Dahlin [EMAIL PROTECTED] To: Linux Kernel linux-kernel@vger.kernel.org I have an Asus Striker Extreme motherboard with two built in MCP55 GigE interfaces. When I build with the original Fedora 7 release kernel ( ftp://ftp.belnet.be/linux/fedora/linux/releases/7/Fedora/i386/os/Fedora/kernel-2.6.21-1.3194.fc7.i686.rpm ) everything works fine. However, when I boot with any updated kernels or any other kernel (have tried building from several points in the linus git tree between 2.6.20 and .23-rc3, and 2.6.21.2 in -stable) I cannot get an IP address via dhcp. There is no error in dmesg. The card shows a link and otherwise appears to be working, but it is as if the dhcp server has been removed from the network. On a running system there is no indication that this is a kernel bug at all, however by varying only the kernel the bug appears and disappears. I've run all these tests repeatedly with no intervening updates of any other packages. As I said I attempted to build 2.6.21.2 ( the point of divergence between the Fedora kernel in question and -stable ) and still the card did not work. I will next attempt to manually build the rpm for the release kernel. If this works I will try experimenting with the included patches to narrow it down, but at this point I'm at a complete loss. -Casey Dahlin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG:] forcedeth: MCP55 not allowing DHCP
Casey Dahlin wrote: I have an Asus Striker Extreme motherboard with two built in MCP55 GigE interfaces. When I build with the original Fedora 7 release kernel ( ftp://ftp.belnet.be/linux/fedora/linux/releases/7/Fedora/i386/os/Fedora/kernel-2.6.21-1.3194.fc7.i686.rpm ) everything works fine. However, when I boot with any updated kernels or any other kernel (have tried building from several points in the linus git tree between 2.6.20 and .23-rc3, and 2.6.21.2 in -stable) I cannot get an IP address via dhcp. There is no error in dmesg. The card shows a link and otherwise appears to be working, but it is as if the dhcp server has been removed from the network. On a running system there is no indication that this is a kernel bug at all, however by varying only the kernel the bug appears and disappears. I've run all these tests repeatedly with no intervening updates of any other packages. As I said I attempted to build 2.6.21.2 ( the point of divergence between the Fedora kernel in question and -stable ) and still the card did not work. I will next attempt to manually build the rpm for the release kernel. If this works I will try experimenting with the included patches to narrow it down, but at this point I'm at a complete loss. -Casey Dahlin Is there any feedback to be had on this? I've gotten no reply whatsoever from several sources now. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG:] forcedeth: MCP55 not allowing DHCP
Casey Dahlin wrote: I have an Asus Striker Extreme motherboard with two built in MCP55 GigE interfaces. When I build with the original Fedora 7 release kernel ( ftp://ftp.belnet.be/linux/fedora/linux/releases/7/Fedora/i386/os/Fedora/kernel-2.6.21-1.3194.fc7.i686.rpm ) everything works fine. However, when I boot with any updated kernels or any other kernel (have tried building from several points in the linus git tree between 2.6.20 and .23-rc3, and 2.6.21.2 in -stable) I cannot get an IP address via dhcp. There is no error in dmesg. The card shows a link and otherwise appears to be working, but it is as if the dhcp server has been removed from the network. On a running system there is no indication that this is a kernel bug at all, however by varying only the kernel the bug appears and disappears. I've run all these tests repeatedly with no intervening updates of any other packages. As I said I attempted to build 2.6.21.2 ( the point of divergence between the Fedora kernel in question and -stable ) and still the card did not work. I will next attempt to manually build the rpm for the release kernel. If this works I will try experimenting with the included patches to narrow it down, but at this point I'm at a complete loss. -Casey Dahlin Is there any feedback to be had on this? I've gotten no reply whatsoever from several sources now. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG:] forcedeth: MCP55 not allowing DHCP
I have an Asus Striker Extreme motherboard with two built in MCP55 GigE interfaces. When I build with the original Fedora 7 release kernel ( ftp://ftp.belnet.be/linux/fedora/linux/releases/7/Fedora/i386/os/Fedora/kernel-2.6.21-1.3194.fc7.i686.rpm ) everything works fine. However, when I boot with any updated kernels or any other kernel (have tried building from several points in the linus git tree between 2.6.20 and .23-rc3, and 2.6.21.2 in -stable) I cannot get an IP address via dhcp. There is no error in dmesg. The card shows a link and otherwise appears to be working, but it is as if the dhcp server has been removed from the network. On a running system there is no indication that this is a kernel bug at all, however by varying only the kernel the bug appears and disappears. I've run all these tests repeatedly with no intervening updates of any other packages. As I said I attempted to build 2.6.21.2 ( the point of divergence between the Fedora kernel in question and -stable ) and still the card did not work. I will next attempt to manually build the rpm for the release kernel. If this works I will try experimenting with the included patches to narrow it down, but at this point I'm at a complete loss. -Casey Dahlin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG:] forcedeth: MCP55 not allowing DHCP
I have an Asus Striker Extreme motherboard with two built in MCP55 GigE interfaces. When I build with the original Fedora 7 release kernel ( ftp://ftp.belnet.be/linux/fedora/linux/releases/7/Fedora/i386/os/Fedora/kernel-2.6.21-1.3194.fc7.i686.rpm ) everything works fine. However, when I boot with any updated kernels or any other kernel (have tried building from several points in the linus git tree between 2.6.20 and .23-rc3, and 2.6.21.2 in -stable) I cannot get an IP address via dhcp. There is no error in dmesg. The card shows a link and otherwise appears to be working, but it is as if the dhcp server has been removed from the network. On a running system there is no indication that this is a kernel bug at all, however by varying only the kernel the bug appears and disappears. I've run all these tests repeatedly with no intervening updates of any other packages. As I said I attempted to build 2.6.21.2 ( the point of divergence between the Fedora kernel in question and -stable ) and still the card did not work. I will next attempt to manually build the rpm for the release kernel. If this works I will try experimenting with the included patches to narrow it down, but at this point I'm at a complete loss. -Casey Dahlin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB Key light on/off state depending on mount
Sorry to have left this dormant for so long. Running eject in either of the ways suggested still leaves the light on my particular key turned on. Stefan Richter wrote: Guennadi Liakhovetski wrote: I might imagine how windows turns the LED off on unmount. Try "eject /dev/sdX", where sdX is your USB storage, after you unmount it. Be careful, especially if you have SATA (or SCSI) discs in your system or if you use libata for PATA discs not to eject the wrong one... If there is only one USB disk connected: # eject /dev/disk/by-path/*usb*:0 Provided you let udev create links for you. BTW, the /dev/disk/by-id/ symlinks are nice for static mount points in /etc/fstab. After a disk was mounted, eject also accepts the mountpoint as parameter and will unmount the disk before it tries to eject it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB Key light on/off state depending on mount
Sorry to have left this dormant for so long. Running eject in either of the ways suggested still leaves the light on my particular key turned on. Stefan Richter wrote: Guennadi Liakhovetski wrote: I might imagine how windows turns the LED off on unmount. Try eject /dev/sdX, where sdX is your USB storage, after you unmount it. Be careful, especially if you have SATA (or SCSI) discs in your system or if you use libata for PATA discs not to eject the wrong one... If there is only one USB disk connected: # eject /dev/disk/by-path/*usb*:0 Provided you let udev create links for you. BTW, the /dev/disk/by-id/ symlinks are nice for static mount points in /etc/fstab. After a disk was mounted, eject also accepts the mountpoint as parameter and will unmount the disk before it tries to eject it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: That whole "Linux stealing our code" thing
Suppose you saw some other variant of *nix that had some code you wanted to use, but there was a gaping security hole in it. Wouldn't you patch it before you incorporated it? and would it be your fault if this fix made the code not work with the original? We took the code and fixed a gaping security vulnerability that appeared within the opening comment. We DO care who does what with our code, and we fully intend to cover our balls. The problem is yours to fix. If you actually care, use a license that SAYS you care. Right now there's a big /* I don't give a shit */ on top of every BSD file. We took you at your word and assumed you didn't. Now its too late and you suddenly care, don't you? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: That whole Linux stealing our code thing
Suppose you saw some other variant of *nix that had some code you wanted to use, but there was a gaping security hole in it. Wouldn't you patch it before you incorporated it? and would it be your fault if this fix made the code not work with the original? We took the code and fixed a gaping security vulnerability that appeared within the opening comment. We DO care who does what with our code, and we fully intend to cover our balls. The problem is yours to fix. If you actually care, use a license that SAYS you care. Right now there's a big /* I don't give a shit */ on top of every BSD file. We took you at your word and assumed you didn't. Now its too late and you suddenly care, don't you? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
USB Key light on/off state depending on mount
Most USB keys nowadays have a small LED somewhere inside of them that lights up when they are plugged in. On a windows box, the key is lit up whenever it is mounted, and as soon as it is unmounted it turns off, giving a handy physical indicator that the key is safe to remove. On linux, the light is simply on whenever the key is plugged in. Should linux toggle the light depending on mount state? Is it as trivial as it seems or does this reflect some larger issue? -Casey Dahlin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
USB Key light on/off state depending on mount
Most USB keys nowadays have a small LED somewhere inside of them that lights up when they are plugged in. On a windows box, the key is lit up whenever it is mounted, and as soon as it is unmounted it turns off, giving a handy physical indicator that the key is safe to remove. On linux, the light is simply on whenever the key is plugged in. Should linux toggle the light depending on mount state? Is it as trivial as it seems or does this reflect some larger issue? -Casey Dahlin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The vi editor causes brain damage
Michael Tharp wrote: Marc Perkel wrote: The important point that you are missing here is that the Linux world is willing to live with an rm command that is broken and the Windows and DOS world isn't. This isn't about the rm command it's about programming standards. It's about that the Linux community isn't committed to getting it right. I wonder, do these sorts of people email random celebrities and tell them they suck? If not, why do they think emailing a developer mailing list about how much they hate their product, work ethics, and general way of life is more socially acceptable? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The vi editor causes brain damage
Michael Tharp wrote: Marc Perkel wrote: The important point that you are missing here is that the Linux world is willing to live with an rm command that is broken and the Windows and DOS world isn't. This isn't about the rm command it's about programming standards. It's about that the Linux community isn't committed to getting it right. I wonder, do these sorts of people email random celebrities and tell them they suck? If not, why do they think emailing a developer mailing list about how much they hate their product, work ethics, and general way of life is more socially acceptable? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
