[rfc] Re: [PATCH] Make UIO available for arm architecture
On Aug 8 2007 18:08, Hans-Jürgen Koch wrote: --- Index: linux-2.6.23-rc/arch/arm/Kconfig === --- linux-2.6.23-rc.orig/arch/arm/Kconfig 2007-08-08 17:52:02.0 +0200 +++ linux-2.6.23-rc/arch/arm/Kconfig 2007-08-08 17:53:29.0 +0200 @@ -1052,6 +1052,8 @@ source drivers/dma/Kconfig +source drivers/uio/Kconfig + endmenu source fs/Kconfig I am raising a general question here. Should not such cross-platform things be made available in a general Kconfig rather than having to patch each arch's Kconfig? I am thinking of drivers/Kconfig for this one (of course I am aware that this requires an extra depends on X86 || SPARC || others in drivers/pci/Kconfig), and perhaps even a top-level Kconfig for things like truly arch-independent fs/Kconfig. Jan --
Re: [fuse-devel] [PATCH 00/25] move handling of setuid/gid bits from VFS into individual setattr functions (RESEND)
On Aug 8 2007 09:48, Andrew Morton wrote: On Mon, 6 Aug 2007 09:54:03 -0400 Jeff Layton [EMAIL PROTECTED] wrote: Is there any way in which we can prevent these problems? Say - rename something so that unconverted filesystems will reliably fail to compile? I suppose we could rename the .setattr inode operation to something else, but then we'll be stuck with it for at least a while. That seems sort of kludgey too... Sure. We're changing the required behaviour of .setattr. Changing its name is a fine and reasonably reliable way to communicate that fact. Maybe -chattr/-chgattr? Jan -- - 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: + remove-current-defines-and-uses-of-pr_err-add-pr_emerg.patch added to -mm tree
On Aug 8 2007 13:31, Joe Perches wrote: Goals in desired implementation sequence: 1 Standardization of pr_level 2 Correctness of single line uses of pr_level 3 Correctness of multiple line uses of printk(level) 4 Removal of local near equivalents of pr_level 5 Standardization of pr_level as single line only 6 Conversion of single line printk(KERN_level to pr_level 7 Standardize local #defines to enable/print pr_level __file__/__func__/__line__ I fail to see what problem these are trying to fix. Please post some broken code that would 'benefit' from pr_halleluja, and why printk(level ) could not do the same. 8 Minimization/elimination of interleaved log messages This is a separate, and worthwhile, thing to do, yes. And it can be done without deviating from the regular printk(). Jan -- - 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: + remove-current-defines-and-uses-of-pr_err-add-pr_emerg.patch added to -mm tree
On Aug 8 2007 14:36, Joe Perches wrote:
On Wed, 2007-08-08 at 22:39 +0200, Jan Engelhardt wrote:
I fail to see what problem these are trying to fix.
Any code that does the equivalent of printk(KERN_foo \n message);
egrep -r printk[[:space:]]*\([[:space:]]*KERN.*\\\n[A-JL-Za-jl-z[:space:]
--include=*.[ch] *
At least 61 instances right now.
Eww. Well, let's look at some.
arch/i386/kernel/io_apic.c:line 1529
printk(\n KERN_DEBUG printing local APIC contents on CPU#%d/%d:\n,
smp_processor_id(), hard_smp_processor_id());
The \n seems unneeded, since print_local_APIC() is run on each cpu.
(see caller).
Then, there are also messages that are just a standalone \n
without even a debugging level. Not sure that is useful.
# io_apic.c again, line 1601
#
printk(KERN_DEBUG ... APIC TDCR: %08x\n, v);
printk(\n);
So, well, let's pick one with KERN_DEBUG \n
fs/freevxfs/vxfs_bmap.c:line 169 (near case VXFS_TYPED_DATA_DEV4)
printk(KERN_INFO \n\nTYPED_DEV4 detected!\n);
printk(KERN_INFO block: %Lu\tsize: %Ld\tdev: %d\n,
(unsigned long long) typ4-vd4_block,
(unsigned long long) typ4-vd4_size,
typ4-vd4_dev);
Seems normal. So it looks like your regex has some false positives.
(which nothing can be done about - the 61 must be hand-sorted)
Perhaps we're looking for this idiom:
printk(KERN_WHATEVER Doing foo...);
for (as_long_as_there_is_work) {
do_it();
printk(KERN_WHATEVER .);
}
printk(KERN_WHATEVER \n);
Yes, that imo is horrible :) since code running on another cpu can printk in
the middle. Perhaps
int i;
for (as_long with ++i) {
do_it();
printk(something informative %d\n, i++);
}
should be done _instead_. This would also address number 8:
8 Minimization/elimination of interleaved log messages
This is a separate, and worthwhile, thing to do, yes.
And it can be done without deviating from the regular printk().
I'm not sure how. Maybe you have an idea you could share?
[My idea is above]
Maybe an external tool to reassemble complete messages from
prefixed {{cookie}} message logs would be fine for awhile.
Perhaps something like:
cookie = printk_block_start()
printk_block[s](cookie)
printk_block_end(cookie)?
where printk_block emits cookie when multiple cookies
are active.
How is this supposed to work? Are you suggesting that the printk buffer is
locked? I hope not. Cache output until a block is ended? No, I do not think
that helps either, because the for(){printk(.);} loops are meant to
give an indication _THAT_ something is happening (or not - e.g. lockup).
Now, if you hold the output of a printk block until it's _end()
counterpart is executed, the user does not get any output when the
machine locks up during the for loop.
Hence, better do a full printk (e.g. with newline) in each iteration.
And if possible sparingly. Booting in 9600 bps serial mode is going to
take longer the more output the kernel produces ;-)
Or just to not clutter dmesg too much.
And at the end of the day when this would be done -
what would we need pr_foo for?
Jan
--
-
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: Documentation files in html format?
On Aug 9 2007 11:31, Stephen Hemminger wrote:
Since the network device documentation needs a rewrite, I was thinking
of using basic html format instead of just plain text. But since this would
be starting an new precedent for kernel documentation, some it seemed
like a worthwhile topic for discussion.
Advantages of html:
* basic formatting like lists, italics, etc
* easier to integrate into other places and retain formatting
* ability to link documents and to external sources easier
Downsides:
* can become too formatted and unclear
So only use h1 to h6, p, b, i, u, ul, ol and li.
Perhaps maybe p class=block with .block{text-align:justify;}
because that looks nice in general.
* accessibility and translation issues?
Accessibility, well, just run w3m instead of less, and you've got it.
Or `w3m -dump xxx.html | less` if you really need it paged.
Translation, no I do not think that is a big issue. But people should
perhaps be kept on the utf-8 toe since html can specify the encoding.
* even more style issues
- two lines between block elements, e.g.
h1/h1\n\np/p\n\nol/ol\n\n..
- tabs used, ol\tlilong long text\n\t\twrapped line/li\n/ol
There is not much to it I think. Use of WYSIWYG editors should be prohibited,
since some reformat the code in terms of line length, aol-ize it
(ol to OL) or replace tags by some synonym.
Jan
--
-
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: Documentation files in html format?
On Aug 9 2007 14:34, Bodo Eggert wrote:
I don't think b and i should be used, instead you should use styles
(span class=code etc).
b does the same as span style=font-weight: bold;, and the latter is much
more verbose for the same thing.
Things like em and strong should be OK, if used consistently.
Perhaps maybe p class=block with .block{text-align:justify;}
because that looks nice in general.
If you like that, you can say p {text-align:justify;} in the default
stylesheet. (And if people would override the alignment, class=block
would be the wrong name).
Oh that comes because MS Office calls it Blocksatz in German ;-)
Jan
--
-
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: Documentation files in html format?
On Aug 9 2007 22:03, Jesper Juhl wrote: On 09/08/07, Stephen Hemminger [EMAIL PROTECTED] wrote: Since the network device documentation needs a rewrite, I was thinking of using basic html format instead of just plain text. But since this would be starting an new precedent for kernel documentation, some it seemed like a worthwhile topic for discussion. Advantages of html: * basic formatting like lists, italics, etc - List item 1 - List item 2 - List item 3 /italic text/ *bold text* _underlined text_ This is likely to generate false positives. Jan -- - 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: problems while mounting /boot partition
On Aug 8 2007 18:28, Michal Piotrowski wrote: Hi Brian, Brian J. Murrell pisze: I am using Ubuntu Gutsy, which is the in-development branch heading for their next stable release. You forgot about message subject, so no one has read this report. Actually, given the volume on LKML, a line without a subject is making the most attention since all others do have one. :) Jan -- - 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: Use of directories to hold root?
On Aug 10 2007 17:24, Mark Cannon wrote: You pass the kernel the root option to specify the root partition. Is there a way to identify a directory in that partition that holds the root or something equivalent to this? No, but you can use pivot_root. Jan -- - 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: Documentation files in html format?
On Aug 10 2007 22:12, Sam Ravnborg wrote: Asciidoc is quite close to plaintext and it looks to me that the formatting possibilities are quite good. How about mediwiki text? '''Users''' :are people who build kernels. '''Normal developers''' :are this and that +=== Goal definitions + +Goal definitions are the main part (heart) of the kbuild Makefile. +These lines define the files to be built, any special compilation +options, and any subdirectories to be entered recursively. + +The most simple kbuild makefile contains one line: + + + obj-y += foo.o + +This tells kbuild that there is one object in that directory, named +foo.o. foo.o will be built from foo.c or foo.S. (wikitext continued) The most simple kbuild makefile contains one line: obj-y += foo.o This tells kbuild that... Jan -- - 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: Use of directories to hold root?
On Aug 10 2007 17:08, H. Peter Anvin wrote: Jan Engelhardt wrote: On Aug 10 2007 17:24, Mark Cannon wrote: You pass the kernel the root option to specify the root partition. Is there a way to identify a directory in that partition that holds the root or something equivalent to this? No, but you can use pivot_root. Or better yet, use an initramfs with MS_MOVE; same as you would with the normal use of initramfs. mount --move /foo / = error What did I miss? Jan -- - 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] Smack: Simplified Mandatory Access Control Kernel
On Aug 11 2007 10:57, Casey Schaufler wrote:
* - pronounced star
wall
_ - pronounced floor
floor
^ - pronounced hat
roof
? - pronounced huh
it's dark in here :)
+config SECURITY_SMACK
+ bool Simplified Mandatory Access Control Kernel Support
+ depends on NETLABEL SECURITY_NETWORK
Is this a hard dependency, or can this work without network sec labels?
+ default n
+ help
+This selects the Simplified Mandatory Access Control Kernel.
+SMACK is useful for sensitivity, integrity, and a variety
+ of other madatory security schemes.
+If you are unsure how to answer this question, answer N.
I smell broken tabs.
+++ linux-2.6.22/security/smack/Makefile 2007-07-10 01:08:05.0
-0700
@@ -0,0 +1,8 @@
+#
+# Makefile for the SMACK LSM
+#
+
+obj-$(CONFIG_SECURITY_SMACK) := smack.o
+
+smack-y := smack_lsm.o smack_access.o smackfs.o
smack-objs :=
+++ linux-2.6.22/security/smack/smack_access.c 2007-07-24 15:36:18.0
-0700
@@ -0,0 +1,113 @@
+extern struct smk_list_entry *smack_list;
+
+static int smk_get_access(smack_t sub, smack_t obj)
+{
+ struct smk_list_entry *sp = smack_list;
proposes const struct. should be used elsewhere too.
+ if (sub == SMK_STAR)
I just remember MechWarrior2 (game from Activison), where SMK stood for their
movie format... it's also a nice abbreviation for Seamonkey (browser suite).
+ if (sub == SMK_HAT ((request MAY_ANYREAD) == request))
+ return 0;
+
+ if (obj == SMK_FLOOR ((request MAY_ANYREAD) == request))
+ return 0;
Redundant parentheses, be gone.
Never was it easier to say what ^ is called in your language :)
if (sub == '^' ...)
return 0;
if (obj == '_' ...)
+/*
+ * The value that this adds is that everything after any
+ * character that's not allowed in a smack will be null
+ */
+smack_t smk_from_string(char *str)
+{
+ smack_t smack = 0LL;
smack_t smack = 0; is enough here.
+ char *cp;
+ int i;
+
+ for (cp = (char *)smack, i = 0; i sizeof(smack_t); str++,cp++,i++) {
Whatever it tries to do, this is not endian-safe. Except if @str
actually points to another smack_t. Yuck.
+ if (*str = ' ' || *str '~')
+ return smack;
+ *cp = *str;
+ }
+ /*
+ * Too long.
+ */
+ return SMK_INVALID;
+}
diff -uprN -X linux-2.6.22-base/Documentation/dontdiff
linux-2.6.22-base/security/smack/smackfs.c
linux-2.6.22/security/smack/smackfs.c
--- linux-2.6.22-base/security/smack/smackfs.c 1969-12-31 16:00:00.0
-0800
+++ linux-2.6.22/security/smack/smackfs.c 2007-07-24 21:51:30.0
-0700
Can't securityfs and/or sysfs be used?
+enum smk_inos {
+ SMK_ROOT_INO = 2,
+ SMK_LOAD = 3, /* load policy */
+ SMK_LINKS = 4, /* symlinks */
+ SMK_CIPSO = 5, /* load label - CIPSO mapping */
+ SMK_DOI = 6, /* CIPSO DOI */
+ SMK_DIRECT =7, /* CIPSO level indicating direct label */
+ SMK_AMBIENT = 8, /* internet ambient label */
+ SMK_NLTYPE =9, /* label scheme to use by default */
+ SMK_TMP = 100,/* MUST BE LAST! /smack/tmp */
+};
Generally, =s are aligned too.
+static struct smk_cipso_entry smack_cipso_floor = {
+.smk_next = NULL,
+.smk_smack = SMK_FLOOR,
+.smk_level = 0,
+.smk_catset = 0LL,
+};
const me.
+/*
+ * ' \n\0'
+ */
I wonder why it's limited to 8 characters? Ah right.. sizeof(smack_t).
uhm.. are you trying to tell me that smack_t [typedef'ed to u64]
are actually meant as a char[8]? (/me scrathces head)
+ for (cp = result; slp != NULL; slp = slp-smk_next) {
+ srp = slp-smk_rule;
+ sprintf(cp, %-8s %-8s,
+ (char *)srp-smk_subject, (char *)srp-smk_object);
I like (const char *).
+ printk(%s:%d bad scan\n,
+ __FUNCTION__, __LINE__);
__FUNCTION__ is a GNU extension, C99 uses __func__.
Not sure what they've got for __LINE__.
+ if (strchr(modestr, 'r') || strchr(modestr, 'R'))
+ rule.smk_access |= MAY_READ;
+ if (strchr(modestr, 'w') || strchr(modestr, 'W'))
+ rule.smk_access |= MAY_WRITE;
+ if (strchr(modestr, 'x') || strchr(modestr, 'X'))
+ rule.smk_access |= MAY_EXEC;
+ if (strchr(modestr, 'a') || strchr(modestr, 'A'))
+ rule.smk_access |= MAY_APPEND;
There's strpbrk() available for you.
+static char *smk_digit(char *cp)
+{
+ for (; *cp != '\0'; cp++)
+ if (*cp = '0' *cp = '9')
+ return cp;
+
+ return NULL;
+}
strpbrk again.
+static int smk_cipso_doied;
+static int smk_cipso_written;
Votes for unsigned int if it {can never be, is not intended to be}
Re: menuconfig should wrap long lines
On Aug 10 2007 17:41, Bernhard Kuemel wrote: Bernhard Kuemel wrote: I was able to view the whole line by making my console window wider, but that may not always be possible so I think it might be better to wrap long lines. Ohh, you can scroll right/left. But still, that takes its time... and the you have to scroll back again :-/ Jan -- - 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] Smack: Simplified Mandatory Access Control Kernel
On Aug 11 2007 16:22, Casey Schaufler wrote:
@@ -0,0 +1,8 @@
+#
+# Makefile for the SMACK LSM
+#
+
+obj-$(CONFIG_SECURITY_SMACK) := smack.o
+
+smack-y := smack_lsm.o smack_access.o smackfs.o
smack-objs :=
Added.
I should have added replace it.
+/*
+ * ' \n\0'
+ */
I wonder why it's limited to 8 characters? Ah right.. sizeof(smack_t).
uhm.. are you trying to tell me that smack_t [typedef'ed to u64]
are actually meant as a char[8]? (/me scrathces head)
Yes. s == o vs strcmp(s,o) == 0.
Evil optimization ;-)
[ s == o is memcmp(s, o, sizeof(that)) == 0]
+ char temp[80];
+ ssize_t rc;
+
+ if (*ppos != 0)
+ return 0;
+
+ sprintf(temp, %d, smk_cipso_doi_value);
+ rc = simple_read_from_buffer(buf, count, ppos, temp, strlen(temp));
80 is plenty for a 11 char string.
Look, they've got funny ideas! :)
net/ipv4/netfilter/nf_nat_irc.c:char buffer[sizeof(4294967296 65635)];
Proposal would have been: char temp[sizeof(4294967296)];
+extern int smack_net_nltype;
+extern int smack_cipso_direct;
+extern struct smk_cipso_entry *smack_cipso;
for consistency reasons, add extern to the other vars too...
the others?
There were some [or some function prototypes] above this point.
+static int smack_task_movememory(struct task_struct *p)
+{
+ int rc;
+
+ rc = smk_curacc(smk_of_task(p), MAY_WRITE);
+ return rc;
+}
Uh...
{
return smk_curacc(smk_of_task(p), MAY_WRITE);
}
(also others)
That was a little excessive, wasn't it?
How do you mean? I was just suggesting to collapse the three [four] lines into
one, getting rid of the tempotemporaries in a lot of these functions,
for example,
+static int smack_task_kill(struct task_struct *p, struct siginfo *info,
+ int sig, u32 secid)
+{
+ smack_t *tsp = smk_of_task(p);
+ int rc;
+
+ /*
+* Sending a signal requires that the sender
+* can write the receiver.
+*/
+ rc = smk_curacc(tsp, MAY_WRITE);
+
+ return rc;
+}
static int smack_task_kill(struct stask_struct *p, struct siginfo *info,
int sig, u32 secid)
{
/* Comment */
return smk_curacc(smk_of_task(p), MAY_WRITE);
}
Jan
--
-
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: [RFC] FUSE: mnotify (was: [RFC] VFS: mnotify)
On Aug 12 2007 06:32, Al Boldi wrote: Al Boldi wrote: Jakob Oestergaard wrote: Why on earth would you cripple the kernel defaults for ext3 (which is a fine FS for boot/root filesystems), when the *fundamental* problem you really want to solve lie much deeper in the implementation of the filesystem? Noatime doesn't solve the problem, it just makes it less horrible. inotify could easily solve the atime problem, but it's got the drawback of forcing the user to register each and every file/dir of interest, which isn't really reasonable on TB-filesystems. What inotify needs is some kind of SUBDIR flag on a watch so that one does not run out of fds, then the TB issue becomes a bit lighter I think. It could be feasible to introduce mnotify, which would notify the user of meta changes, like atime, across the filesystem. Something like mnotify could also be helpful in CoW situations, provided it supported an in-sync interface. Here is an idea: Could FUSE be used to produce mnotify behaviour? It may, and in some cases, not. For example, I only had a single filesystem, and would like atime notificatios for it, then how would I do that? What comes to mind is to use a fuse fs that mirrors, but also notifies, ergo: mount -t fuse.lomount / /mnt Well, wonderful, now I still need to pivot_root to /mnt, so that all accesses actually end up in fuse-land. And this gets ugly on shutdown, when things have to be unmounted. Jan -- - 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: [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid])
On Aug 12 2007 13:35, Al Boldi wrote: Lars Ellenberg wrote: meanwhile, please, anyone interessted, the drbd paper for LinuxConf Eu 2007 is finalized. http://www.drbd.org/fileadmin/drbd/publications/ drbd8.linux-conf.eu.2007.pdf but it does give a good overview about what DRBD actually is, what exact problems it tries to solve, and what developments to expect in the near future. so you can make up your mind about Do we need it?, and Why DRBD? Why not NBD + MD-RAID? I may have made a mistake when asking for how it compares to NBD+MD. Let me retry: what's the functional difference between GFS2 on a DRBD .vs. GFS2 on a DAS SAN? Now, shared remote block access should theoretically be handled, as does DRBD, by a block layer driver, but realistically it may be more appropriate to let it be handled by the combining end user, like OCFS or GFS. Jan -- - 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: menuconfig should wrap long lines
On Aug 12 2007 14:26, Bernhard Kuemel wrote: Jan Engelhardt wrote: [menuconfig] Ohh, you can scroll right/left. But still, that takes its time... and the you have to scroll back again :-/ Yes, but in most cases no scrolling is neccessary, so occasional scrolling is not that bad. It is, on long lines, if you are trying to figure out the selects line. However, I found some long prompts are clipped, too, and there you can not scroll because left/right switches between Select, Exit and Help. The complete prompt can be found in the help screen with scrolling. E.g.: │ │M DiskOnChip 2000, Millennium and Millennium Plus (NAND reimp│ │ │ Prompt: DiskOnChip 2000, Millennium and Millennium Plus (NAND reimplementation) (EXPERIMENTAL) │ Again, most prompts are sufficiently readable on an 80 character terminal. Jan --
Finding out socket/pipe connectivity status
Hi, when a pipe/socket is broken, the process trying to read/write to it gets SIGPIPE. Is there a way to detect whether the next read/write will trigger a SIGPIPE? select() does not seem helpful here. My specific case is ssh server svprogram, in which the ssh process is locally terminated with ^C, and the svprogram continues to run on the server (good so), and when a socket breaks, it should cleanly shut down - ideally before the next read/write is attempted. thanks, Jan -- - 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 01/23] Fall back on interrupt disable in cmpxchg8b on 80386 and 80486
On Aug 12 2007 10:54, Mathieu Desnoyers wrote: Date: Sun, 12 Aug 2007 10:54:35 -0400 From: Mathieu Desnoyers [EMAIL PROTECTED] To: [EMAIL PROTECTED], linux-kernel@vger.kernel.org Cc: Christoph Lameter [EMAIL PROTECTED], Mathieu Desnoyers [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [patch 01/23] Fall back on interrupt disable in cmpxchg8b on 80386 and 80486 Actually, on 386, cmpxchg and cmpxchg_local fall back on cmpxchg_386_u8/16/32: it disables interruptions around non atomic updates to mimic the cmpxchg behavior. The comment: /* Poor man's cmpxchg for 386. Unsuitable for SMP */ already present in cmpxchg_386_u32 tells much about how this cmpxchg implementation should not be used in a SMP context. However, the cmpxchg_local can perfectly use this fallback, since it only needs to be atomic wrt the local cpu. This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64 and cmpxchg64_local on 80386 and 80486. hm, but why is it called cmpxchg_486 when the other functions are called cmpxchg_386? Jan -- - 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: Finding out socket/pipe connectivity status
On Aug 12 2007 17:00, Alan Cox wrote:
when a pipe/socket is broken, the process trying to read/write to it
gets SIGPIPE. Is there a way to detect whether the next read/write will
trigger a SIGPIPE? select() does not seem helpful here.
Processes that are network aware normally set SIGPIPE to SIG_IGN.
The default behaviour comes from a desire that non aware programs
shouldn't get stuck spinning on a network error but go away.
If you ignore the signal you'll get a event from select, and then an
error code.
Yes, SIGPIPE is ignored, because it just occurs at the same time I
can check read() for -1 [=too late].
select considers the broken pipe an error that needs reporting
so it goes ready.
I am in a quite awkward situation. It is about a fuse mount program
operating in xinetd mode (reading/writing to stdin/stdout). When any
of my code is called, I am already involved in a filesystem operation
(e.g. the user called `df`), so there is no point in trying to
handle a broken pipe here. For reference, my_getattr() is,
simplified:
write(stdout, request);
/* reference point [A] */
read(stdin, response);
So my idea had been to launch another thread that monitors stdin for
'breakage' and unmount the fs before a user can start an operation on
myfs. So I've been trying to complete the idea to code. You say a
broken socket raises the read flag, so:
while(1) {
select(STDIN_FILENO+1, read_set, NULL, NULL, NULL);
/* check if broken */
}
but the read flag may also raised during [A] above. So I'd have to
use locking ...
pthread_mutex_lock(lk);
write(stdout, request);
read(stdin, response);
pthread_mutex_unlock(lk);
and
while(1) {
pthread_mutex_lock(lk);
select(STDIN_FILENO+1, read_set, NULL, NULL,
(struct timeval){0, 0});
/* check if broken */
pthread_mutex_unlock(lk);
}
this has the disadvantage that I have to use {0,0} so as to unlock
lk ASAP, otherwise I'd be blocking the write(). Additionally, this
makes it busy-loop, which is not so good. Adding a sleep(60) is a
workaround, but I'd prefer some infinite timeout that cancels on
condition, like e.g. select with a NULL timeout.
Maybe there is a thought bug somewhere and it can be done better.
Your advice is highly appreciated,
thanks,
Jan
--
-
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: [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid])
On Aug 12 2007 09:39, [EMAIL PROTECTED] wrote: now, I am not an expert on either option, but three are a couple things that I would question about the DRDB+MD option 1. when the remote machine is down, how does MD deal with it for reads and writes? I suppose it kicks the drive and you'd have to re-add it by hand unless done by a cronjob. 2. MD over local drive will alternate reads between mirrors (or so I've been told), doing so over the network is wrong. Certainly. In which case you set write_mostly (or even write_only, not sure of its name) on the raid component that is nbd. 3. when writing, will MD wait for the network I/O to get the data saved on the backup before returning from the syscall? or can it sync the data out lazily Can't answer this one - ask Neil :) Jan -- - 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: Software based ECC ?
On Aug 12 2007 18:51, Folkert van Heusden wrote: http://pdos.csail.mit.edu/papers/softecc:ddopson-meng/softecc_ddopson-meng.pdf SoftECC : A System for Software Memory Integrity Checking Personally, I'd recommend just shelling out the bucks for hardware ECC if the reliability matters. a question and an idea: Q: is ecc guaranteed to detect all bitflips? Idea: what about a multicore system (3 or more) that runs the same processes on 2 cores and a third core verifying that they both do the same? As I think it is not only ram that can become faulty. Indeed. And for example BOINC ([EMAIL PROTECTED]) have to consider this. Hence they recalculate each work unit at least three times and then compare between each. What makes this different from ECC is that the checksum is not calculated on every memory operations, but at the end of a larger block of operations. Of course this may mean that an error can propagate for a while, but the total walltime (including recomputation) is lower. :) Jan -- - 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: Use of directories to hold root?
On Aug 12 2007 15:39, Mark Cannon wrote: No, but you can use pivot_root. Or better yet, use an initramfs with MS_MOVE; same as you would with the normal use of initramfs. I am not sure I understand initramfs with MS_MOVE concept. I will look into it. Any pointers for documentation? pivot_root is atomic afaict, for `mount --move` (which I think Al meant which MS_MOVE - or some C program using mount(2) of your own), you'd need multiple calls to mount. Jan -- - 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: Use of directories to hold root?
On Aug 12 2007 21:23, Al Viro wrote: pivot_root is atomic afaict, for `mount --move` (which I think Al meant which MS_MOVE - or some C program using mount(2) of your own), you'd need multiple calls to mount. Move itself is done by a single syscall anyway... Yes, but you need needed 2 mounts, 1 chdir and one chroot. Plus, you have not freed the data in the rootfs. (Well, neither does pivot_root, but run-init from klibc will.) Jan -- - 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: Finding out socket/pipe connectivity status
On Aug 12 2007 19:42, Alan Cox wrote: write(stdout, request); /* reference point [A] */ read(stdin, response); So my idea had been to launch another thread that monitors stdin for 'breakage' and unmount the fs before a user can start an operation on myfs. So I've been trying to complete the idea to code. You say a broken socket raises the read flag, so: Your connection can break at any point even mid-write so you must handle it. You have no real choice. Yes, of course. I was just saying that when the filesystem is in an operation, `df` - sys_statvfs() - [fuse magic] - my_fuse_fs_statfs() I cannot cancel that operation in a way such that df (or /proc/mounts if you like) does not show the mount anymore when the peer is dead. I have to return something. I am fine with that. You can try and spot it earlier by using select/poll and checking for error. In which case I'd use poll() as it is a bit more clear about what event you get Then poll stdin and stdout. The kernel will give you back POLLERR - an error condition POLLHUP - a hangup if at the point you poll an error has already occurred. You can do this with select and the socket error and related stuff buts its uglier poll() alone seems to do just what I want, thank you very much. When the socket breaks, poll raises POLLIN, POLLHUP and POLLRDHUP, but not POLLERR. What exactly is the difference between HUP and RDHUP? The manpage is not too verbose on that. (A guess would be that RDHUP is only for sockets, not pipes.) thanks, Jan -- - 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] Documentation: Fix typo in SubmitChecklist.
On Oct 8 2007 14:55, James Bowes wrote: 20: Check that it all passes `make headers_check'. 21: Has been checked with injection of at least slab and page-allocation -fauilures. See Documentation/fault-injection/. +failures. See Documentation/fault-injection/. It was a fault injection, after all. :) - 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: Linux 2.6.23
On Oct 10 2007 14:36, Alexey Dobriyan wrote: --- linux-2.6.23/include/linux/mm.h.vanilla +++ linux-2.6.23/include/linux/mm.h +struct super_block; extern void drop_pagecache_sb(struct super_block *); void drop_pagecache(void); void drop_slab(void); You probably end up fixing it some other way, but as I do not know this file inside out I just wanted to drop a note. You have some strange vanilla kernel. 2.6.23 doesn't have this prototype. The same happens here as well. -rw-rw-r-- 1 mjt mjt 45488158 Oct 9 20:48 linux-2.6.23.tar.bz2 2cc2fd4d521dc5d7cfce0d8a9d1b3472 linux-2.6.23.tar.bz2 (timestamp is in UTC) Downloaded yesterday, 3 hours after an announce, from http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.23.tar.bz2 . Strange. Same size, same md5, no super_block in mm.h, though Does someone still have the broken tarball? There has not been any drop_pagecache_sb anytime between 2.6.23-rc1 and 2.6.23. drop_pagecache_sb reminds me of reiser4, too. - 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: [OT] Argument with an OS professor over profile=3
On Oct 11 2007 00:13, Russ Dill wrote: /* only text is profiled */ prof_len = (unsigned *) _etext - (unsigned *) _stext; Uh, that's some evil pointer arithmetic :) - 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: Help with rtc to hpet conversion of OSGPS driver
On Oct 11 2007 08:01, Rick Niles wrote: I've been trying to make the driver work with Fedora 7 and the 2.6.22 kernel, but the rtc_register() and other RTC functions seems to have been removed. grep -r rtc_device_register drivers/rtc/ Does that help? I see they've been replaced by the corresponding HPET functions, which is great. However, hpet_register() always returns -16 (EBUSY). This could be because I lack the correct hardware (I'm running 32-bit Linux on a Athlon64 with an NVIDIA chipset) or some other reason. - 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: Help with rtc to hpet conversion of OSGPS driver
On Oct 11 2007 08:51, Rick Niles wrote: Maybe I'm way off here, but that seems to be the function to register a RTC hardware chip with the kernel. I want to use a real-time clock interrupt to wake up my driver and service the GPS correlator, about every 500ms. Please let me know if I'm misunderstanding. You register your hardware, and then the userspace program opens /dev/rtc17 or whatever node is assigned to it, and receives periodic interrupts. At least that's the theory for rtc-cmos. And don't top post. - 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: Getting problem while building kernel module
On Oct 11 2007 15:53, mahamuni ashish wrote: -- [EMAIL PROTECTED] device_driver]# make gcc -O2 -DMODULE -D__KERNEL__ -isystem /usr/src/kernels/2.6.18-1.2798.fc6-i686/include -c -o ins.o ins.c Time to read Documentation/kbuild/. - 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: TPM driver changes to support multiple locality
On Oct 11 2007 11:54, Randy Dunlap wrote: On Thu, 11 Oct 2007 11:33:35 -0700 Agarwal, Lomesh wrote: Below is the patch for TPM driver. Comments/suggestions? Observe/use kernel coding style. Run the patch thru scripts/checkpatch.pl and check its suggestions. Use diffstat -p1 -w70 and put that summary near the top of the patch (after the patch description). Or, if using quilt on top of the tree, a simple `quilt diff --diffstat --sort` will do all the nice diffing, including stat and use diff -pu. It also preserves diffstat (if not regenerating that) and patch description, so is suited *perfectly* for the task when you don't want to use stgit. - 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: [RFD] iptables: mangle table obsoletes filter table
On Oct 12 2007 16:30, Al Boldi wrote: Jan Engelhardt wrote: On Oct 12 2007 00:31, Al Boldi wrote: With the existence of the mangle table, how useful is the filter table? A similar discussion was back in March 2007. http://marc.info/?l=netfilter-develm=117394977210823w=2 http://marc.info/?l=netfilter-develm=117400063907706w=2 in the end, my proposal was something like http://jengelh.hopto.org/GFX0/nf_proposal2.svg Any chance you could publish this as something readable like text/html? Like, image/png? http://jengelh.hopto.org/GFX0/nf_proposal2.png - 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: [RFD] iptables: mangle table obsoletes filter table
On Oct 12 2007 00:31, Al Boldi wrote: With the existence of the mangle table, how useful is the filter table? A similar discussion was back in March 2007. http://marc.info/?l=netfilter-develm=117394977210823w=2 http://marc.info/?l=netfilter-develm=117400063907706w=2 in the end, my proposal was something like http://jengelh.hopto.org/GFX0/nf_proposal2.svg - 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: [RFD] iptables: mangle table obsoletes filter table
On Oct 12 2007 15:48, Patrick McHardy wrote: The netlink based iptables successor I'm currently working on allows to dynamically create tables with user-specified priorities and built-in chains. The only built-in tables will be those that need extra processing (mangle/nat). So it should be possible to set up tables basically any way you desire. Will ebtables move a bit closer to iptables? - 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: oops on rmmod asus_acpi
Hi, I am wondering about asus_acpi-fix-oops-on-non-asus-machines.patch , which is still neither in mainline git nor in Len's acpi git tree ( http://lkml.org/lkml/2007/6/30/29 ). Any plans? thanks, Jan - 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] Allow kconfig to accept overrides
Allow config variables in .config to override earlier ones in the same
file. In other words,
# CONFIG_SECURITY is not defined
CONFIG_SECURITY=y
will activate it. This makes it a bit easier to do
(cat original-config myconfig myconfig2 ... .config)
and run menuconfig as expected.
Previously sent:
http://lkml.org/lkml/2006/10/25/81
http://lkml.org/lkml/2007/4/1/175
Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
Cc: Sam Ravnborg [EMAIL PROTECTED]
Cc: Roman Zippel [EMAIL PROTECTED]
Cc: Randy Dunlap [EMAIL PROTECTED]
---
scripts/kconfig/confdata.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
#
# Applies cleanly to 2.6.22/23/git.
#
Index: linux-2.6.22.1/scripts/kconfig/confdata.c
===
--- linux-2.6.22.1.orig/scripts/kconfig/confdata.c
+++ linux-2.6.22.1/scripts/kconfig/confdata.c
@@ -170,8 +170,7 @@ load:
sym-type = S_BOOLEAN;
}
if (sym-flags def_flags) {
- conf_warning(trying to reassign symbol %s,
sym-name);
- break;
+ conf_warning(override: reassigning to symbol
%s, sym-name);
}
switch (sym-type) {
case S_BOOLEAN:
@@ -210,8 +209,7 @@ load:
sym-type = S_OTHER;
}
if (sym-flags def_flags) {
- conf_warning(trying to reassign symbol %s,
sym-name);
- break;
+ conf_warning(override: reassigning to symbol
%s, sym-name);
}
switch (sym-type) {
case S_TRISTATE:
@@ -288,11 +286,9 @@ load:
}
break;
case yes:
- if (cs-def[def].tri != no) {
- conf_warning(%s creates inconsistent
choice state, sym-name);
- cs-flags = ~def_flags;
- } else
- cs-def[def].val = sym;
+ if(cs-def[def].tri != no)
+ conf_warning(override: %s turns state
choice, sym-name);
+ cs-def[def].val = sym;
break;
}
cs-def[def].tri = E_OR(cs-def[def].tri,
sym-def[def].tri);
-
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: Off-Topic: Patent infringement cases filed in U.S.
On Oct 12 2007 18:25, Renato S. Yamane wrote: IP Innovation LLC has just filed a patent infringement claim against Red Hat and Novell. It was filed October 9, case no. 2:2007cv00447, IP Innovation, LLC et al v. Red Hat Inc. et al, in Texas: I think the number of news sites like lwn,osnews,slashdot,etc is already high enough that no developer would miss out on that. That is, those who even care for such. - 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] Allow kconfig to accept overrides
On Oct 12 2007 14:49, Randy Dunlap wrote: Jan Engelhardt wrote: Allow config variables in .config to override earlier ones in the same file. In other words, # CONFIG_SECURITY is not defined CONFIG_SECURITY=y will activate it. This makes it a bit easier to do (cat original-config myconfig myconfig2 ... .config) and run menuconfig as expected. This is a feature that we want IMO, but I already do this without having a patch for it (although to a lesser degree than full config files; I just cat a few entries to the end of a config file then run oldconfig)... so are there some cases where it works and some cases where it doesn't work? Do you know what those cases are? $ echo CONFIG_CRC7=m ../obj-2.6.23/.config $ make O=/ws/linux/obj-2.6.23 menuconfig GEN /ws/linux/obj-2.6.23/Makefile scripts/kconfig/mconf arch/i386/Kconfig .config:3669:warning: trying to reassign symbol CRC7 (Just save+exit) $ grep CONFIG_CRC7 ../obj-2.6.23/.config # CONFIG_CRC7 is not set - 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] Allow kconfig to accept overrides
On Oct 12 2007 15:57, Randy Dunlap wrote: On Fri, 12 Oct 2007 23:44:08 +0200 (CEST) Jan Engelhardt wrote: warning(override: %s turns state choice, sym-name); What does that warning message mean? I can't decipher it. It is when the value of a choice kconfig object is changed, for example this .config excerpt: CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # CONFIG_PREEMPT_BKL is not set # CONFIG_PREEMPT_NONE is not set CONFIG_REEMPT_VOLUNTARY=y Other than that, it works for me. Thanks. /What/ works, the patch, or the tree without the patch? (Note I was testing that on 2.6.23.1, not the git head, so if someone silently merged things behind me, I might have missed it. Then again, that would have probably caused an offset, fuzz or reject, which was not the case.) - 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] Allow kconfig to accept overrides
On Oct 13 2007 10:16, Stefan Richter wrote: warning(override: %s turns state choice, sym-name); What does that warning message mean? I can't decipher it. It is when the value of a choice kconfig object is changed, for example this .config excerpt: CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # CONFIG_PREEMPT_BKL is not set # CONFIG_PREEMPT_NONE is not set CONFIG_REEMPT_VOLUNTARY=y Perhaps say warning(override: switching to choice %s, sym-name); if sym-name is [CONFIG_]PREEMPT_VOLUNTARY. Or what is it? .config:176:warning: override: reassigning to symbol PREEMPT_VOLUNTARY .config:176:warning: override: PREEMPT_VOLUNTARY turns state choice Which seems correct, as PREEMPT_VOLUNTARY=y will overturn the previous decision. Perhaps it should be %s overturns state choice ? - 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: checkpatch: ERROR: Does not appear to be a unified-diff format patch
On Oct 13 2007 14:47, Adrian Bunk wrote: On Sat, Oct 13, 2007 at 02:28:00PM +0200, Geert Uytterhoeven wrote: scripts/checkpatch.pl doesn't seem to like this patch: $ scripts/checkpatch.pl m68k-export-asm-cachectl-h.diff ERROR: Does not appear to be a unified-diff format patch ... --- a/include/asm-m68k/Kbuild +++ b/include/asm-m68k/Kbuild @@ -1 +1,2 @@ ... ^^ Broken patch, this has to be -1,1. No, this is actually how diff outputs it. /([-+]\d+)\b/ seems to imply /$1,1/ - 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] Allow kconfig to accept overrides
On Oct 13 2007 16:01, Stefan Richter wrote: .config:176:warning: override: reassigning to symbol PREEMPT_VOLUNTARY .config:176:warning: override: PREEMPT_VOLUNTARY turns state choice Try to make it a single warning. Patches welcome. Even without the patch, i.e. original kconfig behavior, spews two warnings. One for the symbol, and one for the choiec object. I do not see anything wrong with that; adding extra checks would perhaps only increase the code size. - 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] Allow kconfig to accept overrides
On Oct 13 2007 09:25, Randy Dunlap wrote: Jan Engelhardt wrote: On Oct 13 2007 16:01, Stefan Richter wrote: .config:176:warning: override: reassigning to symbol PREEMPT_VOLUNTARY .config:176:warning: override: PREEMPT_VOLUNTARY turns state choice .config:176:warning: override: PREEMPT_VOLUNTARY modifies state choice turns is just odd there. Yeah, I've put in (override: %s changes choice state, sym-name); this morning. - 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: regression(?): starting with 2.6.21 sending packets became broken.
On Oct 13 2007 19:59, David wrote: Try echo 0 /proc/sys/net/ipv4/tcp_window_scaling I bet you have broken router(s) between your machine and the problem site(s). There is an xt_TCPOPTSTRIP module in the works that allows you to strip Window Scaling only on the connections you want (rather than globally); seems to be in for 2.6.24 at earliest, though it's there is also the standalone patch. - 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: wierd file perms
On Oct 14 2007 14:30, Bauke Jan Douma wrote: On Sat, 2007-10-13 22:40:23 +0530, vignesh babu [EMAIL PROTECTED] wrote: I was surprised and did an ls -l on the files and guess what I found: total 0 ?- ? ? ? ?? fcntl.c ?- ? ? ? ?? fifo.c ?- ? ? ? ?? filesystems.c ?- ? ? ? ?? file_table.c ?- ? ? ? ?? freevxfs So end result is that, Im not able to delete the files or change perms or ownership even as root. Most probably, your filesystem is broken and needs a fsck. I don't think this is a bug, but a feature of 'ls', see for instance the coreutils mailing list: http://lists.gnu.org/archive/html/bug-coreutils/2007-05/msg00226.html - broken on-disk fs - you are not allowed to stat() -- which can only reasonably happen with FUSE or remote filesystems - ls also outputs ?- if the file mode does not make sense, though as we can see, UID/GID nlink, etc. are also missing, so I suspect item 2. - 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: wierd file perms
On Oct 14 2007 09:27, Mark Lord wrote: Jan-Benedict Glaw wrote: On Sat, 2007-10-13 22:40:23 +0530, vignesh babu [EMAIL PROTECTED] wrote: I was surprised and did an ls -l on the files and guess what I found: total 0 ?- ? ? ? ?? fcntl.c ?- ? ? ? ?? fifo.c ?- ? ? ? ?? filesystems.c ?- ? ? ? ?? file_table.c ?- ? ? ? ?? freevxfs So end result is that, Im not able to delete the files or change perms or ownership even as root. Most probably, your filesystem is broken and needs a fsck. No, this is perfectly normal behaviour, for when a directory has READ permissions but not EXECUTE permissions. Er, close. 16:02 ichi:/dev/shm md a 16:02 ichi:/dev/shm touch a/b 16:02 ichi:/dev/shm chmod 644 a 16:02 ichi:/dev/shm ls -l a /bin/ls: cannot access a/b: Permission denied total 0 -? ? ? ? ?? b 16:02 ichi:/dev/shm ls --version ls (GNU coreutils) 6.9 There is a difference .. -? vs ?-. The first looks to me like filetype known (S_IFREG), while the latter is filetype and mode unknown. - 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: System.map
On Oct 14 2007 19:07, Philip wrote: I want to write a script, which shows the name of the relevant kernel module for each listed pci device shown by 'lspci -m'. It's easy to find out the name of the corresponding module, if the driver has been compiled as a loadable kernel module: The file /lib/modules/$(uname -r)/modules.pcimap lists module names based on pci device's vendor -and device id (shown by 'lspci -n'). But how can I find out the name of the corresponding kernel module if the module has been compiled directly into the kernel ? Well if it is compiled in, it is not a module, so you cannot find it the usual way. I thought that I can find them in the kernel's machting System.map based on vendor -and device id as well. But I can't find those id's there. Where do I have to look for it ? I want to be informed by my script, if the driver (module) for a specific pci device is available as a loadable module, in-kernel module or not available at all. That does not work reliably either. There might be PCI devices which have the same PID:VID, but need a readb() or so for further finding out whether the actual piece of hardware has a driver. And then there is that sort of modules which do not have typical IDs (i.e. udev cannot/won't autoload them) at all, like pcspkr.ko/psmouse.ko - 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: In response to kernel compression e-mail a few months ago.
On Oct 14 2007 15:34, Justin Piszcz wrote: It turns out the one I did not test, was actually the best: Used: 7z -mx=9 a linux-2.6.16.17.tar.7z linux-2.6.16.17.tar $ du -sk * | sort -n 32392 linux-2.6.16.17.tar.7z 33520 linux-2.6.16.17.tar.lzma 33760 linux-2.6.16.17.tar.rar 38064 linux-2.6.16.17.tar.rz 39472 linux-2.6.16.17.tar.szip 39520 linux-2.6.16.17.tar.bz 39936 linux-2.6.16.17.tar.bz2 4 linux-2.6.16.17.tar.bicom 40656 linux-2.6.16.17.tar.sit 47664 linux-2.6.16.17.tar.lha 49968 linux-2.6.16.17.tar.dzip 5 linux-2.6.16.17.tar.gz 51344 linux-2.6.16.17.tar.arj 57552 linux-2.6.16.17.tar.lzo 57984 linux-2.6.16.17.tar.F 81136 linux-2.6.16.17.tar.Z 94544 linux-2.6.16.17.tar.zoo 101216 linux-2.6.16.17.tar.arc 228608 linux-2.6.16.17.tar What's with all these odd formats, and where is .zip? :) Somehow... have you tried lrzip? Furthermore, if the files in the .tar archive were actually sorted.. (Obviously we shall pick .7z) - 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: In response to kernel compression e-mail a few months ago.
On Oct 14 2007 15:53, Justin Piszcz wrote: What's with all these odd formats, and where is .zip? :) Somehow... have you tried lrzip? $ apt-cache search lrzip $ I tried most of the main ones in the standard testing distribution within Debian. Debian is not a solution to everything. http://ck.kolivas.org/apps/lrzip/ - 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: In response to kernel compression e-mail a few months ago.
On Oct 14 2007 16:58, Justin Piszcz wrote: compress: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 10544 war 20 0 700m 681m 1632 S 141 20.7 1:41.46 7z Just how you can utilize a CPU to 141% remains a mystery.. [ to be noted this is sqrt(2)*100 ] - 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: WANTED: kernel projects for CS students
On Oct 15 2007 18:36, Philippe Elie wrote: Isn't make -j 2 or more implemented by running multiple make in sub-dirs ? Parallel make is more and more used even on cheap hardware. Errm, I misread what you said, it can be a single Makefile in each sub-dirs Even now, make -j8 really pays off on bigiron AMD. - 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][rfc] rewrite ramdisk
On Oct 16 2007 17:47, Nick Piggin wrote:
Here's a quick first hack...
Inline patches preferred ;-)
+config BLK_DEV_BRD
+ tristate RAM block device support
+ ---help---
+This is a new based block driver that replaces BLK_DEV_RAM.
based on what? -^
+To compile this driver as a module, choose M here: the
+module will be called rd.
called brd.ko.
+/*
+ * And now the modules code and kernel interface.
+ */
+static int rd_nr;
+static int rd_size = CONFIG_BLK_DEV_RAM_SIZE;
Perhaps unsigned?
Perhaps even long for rd_size?
+module_param(rd_nr, int, 0);
+MODULE_PARM_DESC(rd_nr, Maximum number of brd devices);
+module_param(rd_size, int, 0);
+MODULE_PARM_DESC(rd_size, Size of each RAM disk in kbytes.);
+MODULE_LICENSE(GPL);
+MODULE_ALIAS_BLOCKDEV_MAJOR(RAMDISK_MAJOR);
+
+/* options - nonmodular */
+#ifndef MODULE
+static int __init ramdisk_size(char *str)
+{
+ rd_size = simple_strtol(str,NULL,0);
+ return 1;
+}
Is this, besides for compatibility, really needed?
+static int __init ramdisk_size2(char *str)
+{
+ return ramdisk_size(str);
+}
+static int __init rd_nr(char *str)
Err! Overlapping symbols! The rd_nr() function collides with the rd_nr
variable. It also does not seem needed, since it did not exist before.
It should go, you can set the variable with brd.rd_nr=XXX (same
goes for ramdisk_size). What's the point of ramdisk_size2()?
+{
+ rd_nr = simple_strtol(str, NULL, 0);
+ return 1;
+}
+__setup(ramdisk=, ramdisk_size);
+__setup(ramdisk_size=, ramdisk_size2);
__setup(ramdisk_size=, ramdisk_size); maybe, or does not that work?
+__setup(rd_nr=, rd_nr);
+#endif
+
+
+static struct brd_device *brd_alloc(int i)
+{
+ struct brd_device *brd;
+ struct gendisk *disk;
+
+ brd = kzalloc(sizeof(*brd), GFP_KERNEL);
+ if (!brd)
+ goto out;
+ brd-brd_number = i;
-
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][rfc] rewrite ramdisk
On Oct 16 2007 18:07, Nick Piggin wrote: Changed. But it will hopefully just completely replace rd.c, so I will probably just rename it to rd.c at some point (and change .config options to stay compatible). Unless someone sees a problem with that? I do not see a problem with keeping brd either. It also does not seem needed, since it did not exist before. It should go, you can set the variable with brd.rd_nr=XXX (same goes for ramdisk_size). But only if it's a module? Attributes always work. Try vt.default_red=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 and you will see. - 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][rfc] rewrite ramdisk
On Oct 16 2007 18:26, Nick Piggin wrote: It also does not seem needed, since it did not exist before. It should go, you can set the variable with brd.rd_nr=XXX (same goes for ramdisk_size). But only if it's a module? Attributes always work. Try vt.default_red=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 and you will see. Ah, nice. (I don't use them much!). Still, backward compat I think is needed if we are to replace rd.c. Like I said, I did not see rd_nr in Documentation/kernel-parameters.txt so I thought there was no compat. - 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: In response to kernel compression e-mail a few months ago.
On Oct 16 2007 14:19, Denys Vlasenko wrote: Sizes in Kb again: 32392 linux-2.6.16.17.tar.7z 33520 linux-2.6.16.17.tar.lzma P.S. sorting files by extension in tarball generally helps, but in case of Linux kernel, they are all C code anyway, so no measurable gain there. Extension is not all so interesting because, as you point out, most of it is C code, and .h files are mostly like .c in that they have structs and function prototype keywords. But sorting by name buys: -rw-r--r-- 1 jengelh users 45477128 Oct 12 18:47 linux-2.6.23.1.orig.tar.bz2 -rw-r--r-- 1 jengelh users 45560647 Oct 16 16:18 linux-2.6.23.1.new.tar.bz2 (actually, `find $@ -print0 | sort -z | tar -T- --null --no-r --owner=root --group=root -cvjf $output;` was used) - 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] Allow kconfig to accept overrides
Hi Sam, On Oct 16 2007 06:29, Sam Ravnborg wrote: On Fri, Oct 12, 2007 at 11:44:08PM +0200, Jan Engelhardt wrote: Allow config variables in .config to override earlier ones in the same file. In other words, # CONFIG_SECURITY is not defined CONFIG_SECURITY=y will activate it. This makes it a bit easier to do (cat original-config myconfig myconfig2 ... .config) and run menuconfig as expected. How far is this from the miniconfig functionality? Is it the same or can we achieve the miniconfig support by extending Jan's patch? See: http://lkml.org/lkml/2007/10/12/391 miniconfig actually does something completely different as far as I understand: miniconfig creates a minimal config that does not contain default choices for CONFIG_ files, while the patch that I was trying to submit here allows to override entries in a .config by just appending them to the file. I already have a miniconfig, so to speak, and want to merge it with the previous .config so as to produce a fullconfig. (Something like the exact opposite) thanks, Jan - 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: WANTED: kernel projects for CS students
On Oct 16 2007 13:06, Mark Gross wrote: base function: Starting from a stock distro (FC, Ubuntu, OpenSuSE...) and put down a kernel.org tree and automatically create a .config with all the drivers needed for the platform I'm building on. Too easy. Since opensuse's udev loads most of the modules for your hardware, all that would be needed is to transform the lsmod list of modules plus the static options in /proc/config.gz (stuff like psmouse) back into kconfig options ;-) - 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: WANTED: kernel projects for CS students
On Oct 16 2007 16:23, Rik van Riel wrote: base function: Starting from a stock distro (FC, Ubuntu, OpenSuSE...) and put down a kernel.org tree and automatically create a .config with all the drivers needed for the platform I'm building on. Too easy. Since opensuse's udev loads most of the modules for your hardware, all that would be needed is to transform the lsmod list of modules plus the static options in /proc/config.gz (stuff like psmouse) back into kconfig options ;-) Well, at that point it does not know whether or not you occasionally plug in an ipod or a digital camera. Which is why building an allmod kernel (or what the distros do) is IMO the better solution. - 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: Community research
On Oct 17 2007 15:13, Kristoffer Ericson wrote: 536 total / 472 from Hungary / 4 United States / 1 Ukraine / 1 UK / 1 Turkey / 2 Sweden / 4 Slovakia / 1 Singapore / 2 Serbia / 2 Russia / 7 sweden only 2? And how did Hungary get so many developers? Supposedly gave the link to all friends and/or forums in the area. Yes, this shows one thing: LKML is largely not interested in surveys. Way too many students decide to take surveys (which are not even LKML-centric!), it is getting boring - that is my impression. - 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] vc bell config
On Oct 11 2007 18:11, Pavel Machek wrote: It is already possible to deactivate the vc bell on a per-tty basis, by using echo -en \e[11;0], but this is reset on reset(1). This adds a sysfs parameter to globally control the vc bell, as well as sysfs parameters for default pitch and duration. Signed-off-by: Jan Engelhardt [EMAIL PROTECTED] There are more parameters that should be set during reset... like cursor size and color, palette, What about /sys/.../string_to_interpret _on_reset ? On reset(1), cursor size, palette, and bell parameters _do_ get reset to the defaults. Some defaults may already be changed by the user, like palette or default_utf8. Bell configuration is currently not one of them so, should a program decide to reset the tty, or should it happen that your output is garbled (forcing you to do reset), some settings change back to unwanted defaults. - 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: your mail
On Oct 17 2007 16:30, [EMAIL PROTECTED] wrote: Date: Wed, 17 Oct 2007 16:30:24 + From: [EMAIL PROTECTED] To: linux-kernel@vger.kernel.org ^^ subscribe linux-alpha ^ - 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: How to register block device as read-only
On Jul 28 2007 13:36, Bernd Petrovitsch wrote: Unless I misunderstand the question, the write and writev function of the struct file_operations should return an appropriate error value (which is here -EACCES). You may think of returning an error in the open if someone wants to open it to write to it (so that the must open it read-only). But I don't know if that is common practice or not (or even disliked) as it may interfere with not properly implemented tools which open devices read-write even if they never write to it. Yes it is, I believe. When mount(8) gets an error from mount(2), it retries with MS_RDONLY enabled. Jan -- - 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: zd1211b question.
On Jul 28 2007 07:55, Gene Heskett wrote: Greetings all; A net friend of mine has a Gateway m305CRV laptop, with this radio in it: Bus 003 Device 003: ID 050d:705c Belkin Components Its apparently sitting on the usb bus, and from my grepping of the kernel srcs, it looks as if the zd1211b driver might be the correct one: [...] This last one is the right set of numbers. However, I'll be dipped but I can't find anyplace in a make xconfig in the 2.6.22.1-rt9 tree, to turn on the building of that driver. Am I blind, don't know how to run grep, or does the xconfig script need more tlc? Can somebody toss me a bone of info here? cat drivers/net/wireless/zd1211rw/Kconfig? Jan -- - 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: [ck] Re: Linus 2.6.23-rc1
On Jul 28 2007 10:12, Linus Torvalds wrote: The fact is, I've _always_ considered the desktop to be the most important part. [...] The fact is, most kernel developers realize that Linux is used in different places, on different machines, and with different loads. You cannot make _everybody_ happy, but you can try to do as good a job as possible. And doing as good a job as possible very much includes not focusing on any particular load. You cannot please everybody in the scheduler question, that is clear, then why not offer dedicated scheduling alternatives (plugsched comes to mind) and let them choose what pleases them most, and handles their workload best? Jan -- - 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: Linus 2.6.23-rc1
On Jul 28 2007 10:50, Linus Torvalds wrote: On Sat, 28 Jul 2007, Kasper Sandberg wrote: First off, i've personally run tests on many more machines than my own, i've had lots of people try on their machines, and i've seen totally unrelated posts to lkml, plus i've seen the experiences people are writing about on IRC. Frankly, im not just thinking of myself. Ok, good. Has anybody tried to figure out why 3D games seem to be such a special case? Is it specific to 3D? I would not think so. dosbox, bochs should have the same issue. Games with a lot of motion usually implement their event handling and screen drawing in a busy loop to get the maximum possible frame rate. Usually, only the GL thread would need to run at full power, and reducing the input subsystem to a simple event-based loop (for example reading a pipe in blocking mode). This could IMO makes games a bit more responsive. However, most games combine the input subsystem and graphics output in one thread. Due to the way CFS works, it may mean that processes get scheduled too fair, though I'd suspect that a GL busy loop has no interactivity bonus at all anyway in the old scheduler or SD. I/O is also something that can hurt games in their framerate and/or handling (something the user cares most about). Since I have not tried 2.6.23-rc yet, I can only speak for the old scheduler. I have always turned cron off so that updatedb does not run, because it makes games sluggish for some reason, even though updatedb (or subordinate processes) don't take a lot of CPU time according to `top`. What's more, running BOINC in the background (nice 20) while running unreal (nice 0), everything is ok. (But not if BOINC is at nice 0). Time to investigate... Jan -- - 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: [ck] Re: Linus 2.6.23-rc1
On Jul 28 2007 22:51, Diego Calleja wrote: El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds [EMAIL PROTECTED] escribió: So modal things are good for fixing behaviour in the short run. But they are a total disaster in the long run, and even in the short run they tend to have problems (simply because there will be cases that straddle the line, and show some of _both_ issues, and now *neither* mode is the right one) I fully agree with this, but plugsched could have avoided this useless division on the topic of SD vs CFS. IMO that counts as an advantage, too ;) It's like CONFIG_HZ - more or less often debated, and now we have everyone happy by giving them the choice. Jan --
Re: Linus 2.6.23-rc1
On Jul 28 2007 14:33, Linus Torvalds wrote: Btw, people who actually have 3D games installed (I have exactly one: ppracer, and I can't really say that I care about how it feels), if you don't have CONFIG_HZ=1000, this really is worth testing. I think Ingo probably ran with CONFIG_NO_HZ and HZ_1000, but the default timer tick is actually 250Hz, which makes all the default scheduler values come out four times bigger than they are documented/supposed to be. I generally run with CONFIG_HZ=100, CONFIG_NO_HZ=n, CONFIG_PREEMPT_NONE. Jan -- - 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: TCP SACK issue, hung connection, tcpdump included
On Jul 29 2007 08:45, Willy Tarreau wrote: On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote: CLIENT = Linux 2.6.20.1-smp [Customer build] SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS release 4 (Nahant Update 5)] The problems start around time index 09:21:39.860302 when the CLIENT issues a TCP packet with SACK option set (seemingly for a data segment which has already been seen) from that point on the connection hangs. Where was the capture taken ? on CLIENT or on SERVER (I suspect client from the timers) ? A possible, but very unlikely reason would be an MTU limitation somewhere, because the segment which never gets correctly ACKed is also the largest one in this trace.[...] I had something similar (and most strangely enough, it only seemed to happen when the source and/or destination address was outside a given subnet). It boiled down to that some switch acted really strange and God knows why. A tcpdump on *both* sides (server+client) each showed that the *other* peer sent a FIN/RST. Well in the end I settled with setting sys.net.ipv4.tcp_sack=0, no idea if the broken switch got replaced in the meantime. Well, just letting you know that it is not limited to computers. Jan -- - 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] .gitignore update
On Jul 26 2007 16:15, Alexey Dobriyan wrote: Somehow I ended up with the following in tree: $ git status ... # Untracked files: # (use git add file... to include in what will be committed) # # fs/proc/root.o.FuMxJQ # net/ipv4/tcp_minisocks.o.geCDYR These are presumably temporary gcc files, which aren't interesting. But they should not be there by default! Or are they? Looks like an interrupted assembler stage or so. So I do not think *.o.* should be added. Jan -- - 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: nvidia installer DIW with 2.6.23-rc1
On Jul 29 2007 10:57, Gene Heskett wrote: /tmp/selfgz9678/NVIDIA-Linux-x86-100.14.11-pkg1/usr/src/nv/nv.c: In function ‘nvidia_init_module’: /tmp/selfgz9678/NVIDIA-Linux-x86-100.14.11-pkg1/usr/src/nv/nv.c:1326: error: too many arguments to function ‘kmem_cache_create’ Is this a known problem? Do I need to report it to nvidia somehow? Well, you do not *need* to report it, just as you do not need to report kernel oopses or Windows crashes. They'll eventually stumble upon that themselves It looks to me like it may be their problem, and I have submitted it, but if anyone has a better idea, please advise. System is FC6, uptodate as of yesterday. Better idea? Fix the source until they have a fix. It seems to be just an extra argument to kmem_cache_create that got removed. Jan --
Re: request for patches: showing mount options
[cc trim on purpose, just autofs interest here] On Jul 28 2007 14:45, Ian Kent wrote: Oh .. sorry, I wasn't paying enough attention. But now might be a good time to propose the removal of autofs and rename autofs4 to autofs. I would need to provide some way to map autofs4 module load requests to autofs for backward compatibility but haven't thought about that yet. You could use EXPORT_SYMBOL in autofs.ko that autofs4.ko uses. Or write an autofs4.c that does try_module_get(autofs) on _init. Jan -- - 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: nvidia installer DIW with 2.6.23-rc1
On Jul 29 2007 14:12, Mike Houston wrote:
I know it's off topic here, but this will help people.
When that happens, check their forum. Chances are someone has
posted, and the nvidia developers have answered with a patch, code
snippet, quick instructions to get it to compile or advice to try a
beta driver if applicable.
At least for solidarity for those stuck with it, patch below.
To build nvidia kernel module failed in
kernel-2.6.23-0.41.rc0.git14.fc8
http://www.nvnews.net/vbulletin/showthread.php?t=95296
Jan
===
---
nv-linux.h |2 +-
nv.c |6 ++
2 files changed, 3 insertions(+), 5 deletions(-)
Index: nv_kernel-100.14.11/nv-linux.h
===
--- nv_kernel-100.14.11.orig/nv-linux.h
+++ nv_kernel-100.14.11/nv-linux.h
@@ -533,7 +533,7 @@ static inline unsigned long nv_virt_to_p
#define NV_KMEM_CACHE_CREATE(kmem_cache, name, type)\
{ \
kmem_cache = kmem_cache_create(name, sizeof(type), \
-0, 0, NULL, NULL); \
+0, 0, NULL); \
}
#define NV_KMEM_CACHE_DESTROY(kmem_cache) \
Index: nv_kernel-100.14.11/nv.c
===
--- nv_kernel-100.14.11.orig/nv.c
+++ nv_kernel-100.14.11/nv.c
@@ -1566,8 +1566,7 @@ failed:
if (apm_nv_dev[i] != NULL) pm_unregister(apm_nv_dev[i]);
#endif
-if (unregister_chrdev(nv_major, nvidia) 0)
-nv_printf(NV_DBG_ERRORS, NVRM: unregister nv chrdev failed\n);
+unregister_chrdev(nv_major, nvidia);
for (i = 0; i num_nv_devices; i++)
{
@@ -1598,8 +1597,7 @@ static void __exit nvidia_exit_module(vo
nv_printf(NV_DBG_INFO, NVRM: nvidia_exit_module\n);
-if (unregister_chrdev(nv_major, nvidia) 0)
-nv_printf(NV_DBG_ERRORS, NVRM: unregister nv chrdev failed\n);
+unregister_chrdev(nv_major, nvidia);
for (i = 0; i num_nv_devices; i++)
{
-
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: 2.6.23-rc1, spamassassin vs rpc stuffs, rpc 1, spamassassin 0
On Jul 30 2007 07:16, H. Peter Anvin wrote: Guillaume Chazarain wrote: Comments anyone? This is not specific to the kernel. It was discussed here: http://lkml.org/lkml/2007/1/24/258 http://cyberelk.net/tim/portreserve/ seems to be the solution, it's a pity it is not widely deployed. The better solution probably would have bindresvport() in glibc be aware of a blacklist. I am sure it already is. 16:21 ichi:/ws/iptables l /etc/bindresvport.blacklist -rw-r--r-- 1 root root 332 Nov 25 2006 /etc/bindresvport.blacklist But that may be a patch local to openSUSE. Jan -- - 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: [DRIVER SUBMISSION] DRBD wants to go mainline
On Jul 30 2007 21:35, Lars Ellenberg wrote: On Fri, Jul 27, 2007 at 06:46:17PM +, Pavel Machek wrote: Hi! We implement shared-disk semantics in a shared-nothing cluster. If nothing is shared, the disk is not shared, but got shared-disk semantics? A little confusing. Think of it as RAID1 over TCP. Getting back at that... How does it compare (in terms of do we need it?) to RAIF1 over NFS? Jan -- - 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: Inclusion of vmware mptbase regression fix
On Jul 31 2007 20:24, Maarten Bressers wrote: Hi Petr, The patch you posted for the MPT Fusion driver regression with VMware 5.5.4 (http://lkml.org/lkml/2007/3/23/345) was used to fix a Gentoo kernel bug (http://bugs.gentoo.org/show_bug.cgi?id=185272). Have you received word from upstream (kernel devs) yet as to whether your patch will be included? Or if it will be included at all? Since it is a problem not specific to the kernel, no 'fix' or workaround is going to be included. Jan -- - 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 -mm] Introduce U16_MAX and U32_MAX
On Jul 31 2007 11:57, Andrew Morton wrote: --- a/include/linux/kernel.h +++ b/include/linux/kernel.h @@ -30,6 +30,9 @@ extern const char linux_proc_banner[]; #define LLONG_MIN (-LLONG_MAX - 1) #define ULLONG_MAX (~0ULL) +#define U16_MAX ((u16) ~0U) +#define U32_MAX ((u32) ~0U) + hm, I'd have thought that there's a risk of gcc warnings here, forcing 0x into a u16, but apparently not. No, since it is casted (= explicitly truncated). Jan -- - 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: Linus 2.6.23-rc1
On Jul 28 2007 12:34, Linus Torvalds wrote: On Sat, 28 Jul 2007, Jan Engelhardt wrote: Time to investigate... Well it really is different. Simple test: - run Unreal Tournament 99 (nice 0, it gets 98%,99% CPU most of the time) - in a shell, `renice 20 $$; while :; do date; done;` The shell only produces one or two outputs per second. This seems different from the old-2.6 behavior, where a nice-20 process seemed to get a bit more share. (Due to interactivity bonus) Does anyone have a cpu hog test program that spreads its cpu time over the second rather than doing 300 ms wake and 700 ms sleep cycles after another? Well, one thing that would be worth doing is to simply create a trace of time-slices for both schedulers. It could easily be some hacky thing that just saves the process name and TSC at each scheduling event in some fairly small fixed-sized per-CPU circular buffer, and have a /sys interface that reads it out, and then you do sleep 60 ; cat /sys/cpubuffer buffer and play the game for 60 seconds (so that you get a buffer that represents perhaps the last 10 seconds of play). Send me patches, I run the test. It could *literally* just be an effect of the time quanta used, and CFS just deciding that it's not interactive and giving things too long of a CPU slice. Yes, it's what /proc/sys/kernel/sched_granularity_ns is supposed to tweak, but maybe there's some misfeature there, or maybe the default is just bad for games, or whatever. Ingo: that sysctl_sched_granularity initialization doesn't make sense. You talk about it being in units of nanoseconds, but then you do 20ULL/HZ which is nonsensical. That value is 2 seconds (not 2ms like the comment says) in nanoseconds, but then divided by HZ, so what's the meaning of that HZ thing? Nothing in the scheduler should care about jiffies, why is that related to HZ? All the scheduler clocks are in ns. Linus Jan -- - 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: [RFC PATCH] type safe allocator
On Aug 1 2007 12:45, Miklos Szeredi wrote: #define k_new(type, flags) ((type *) kmalloc(sizeof(type), flags)) The cast doesn't make it more safe in any way I does, since a warning will be issued, if the type of the assigned pointer doesn't match the requested allocation. And yes, warnings are _very_ useful in C for enforcing type safety. void *p; p = (struct foo *)kmalloc(sizeof(struct foo), GFP_KERNEL); Jan -- - 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: [RFC 12/26] ext2 white-out support
On Aug 1 2007 12:00, Hans-Peter Jansen wrote: *) The amount of administration work of any (necessary, unfortunately) VMware XP instance running on top of those diskless clients excels that of all diskless clients by an order of magnitude. Hardly :) Install XP, snapshot it when done. Copy .vmdk to 'all' machines. On security upgrades, revert to snapshot (well - if the workflow allows it), install, snapshot again. Etc. Work: 1 1/2. Jan -- - 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: [RFC 12/26] ext2 white-out support
On Jul 31 2007 12:36, Josef Sipek wrote: [2] http://www.filesystems.org/unionfs-odf.txt Instead, the new ODF code stores whiteouts as hardlinks to a special (regular) zero-length file in odf (/odf/whiteout), and it stores opaqueness information for directories in the inode GID bits in an ODF file system (e.g., ext2, XFS, etc.) on the local machine. This avoids the name-space pollution and avoids races with network file systems, while minimizing inode consummation in /odf. Inode GID bits - are you reducing my 32 bits of gid_t to 31 bits? That does not work out either. Jan -- - 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: [RFC] [PATCH] Deprecate a.out ELF interpreters
On Aug 1 2007 14:33, Andi Kleen wrote: Comments? A kconfig entry (OBSOLETE)/(DEPRECATED) would be nice. (And if you want to test people, 'depends on EMBEDDED' for CONFIG_BINFMT_AOUT) Jan -- - 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: [RFC] [PATCH] Deprecate a.out ELF interpreters
On Aug 1 2007 20:35, Andi Kleen wrote: On Aug 1 2007 14:33, Andi Kleen wrote: Comments? A kconfig entry (OBSOLETE)/(DEPRECATED) would be nice. (And if you want to test people, 'depends on EMBEDDED' for CONFIG_BINFMT_AOUT) The point is to have less clutter in binfmt_elf.c (which really could need a rewrite btw or at least a lot of cleanup) not add more in form of ifdefs. --- fs/Kconfig.binfmt |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.23/fs/Kconfig.binfmt === --- linux-2.6.23.orig/fs/Kconfig.binfmt +++ linux-2.6.23/fs/Kconfig.binfmt @@ -56,7 +56,7 @@ config BINFMT_SHARED_FLAT Support FLAT shared libraries config BINFMT_AOUT - tristate Kernel support for a.out and ECOFF binaries + tristate Kernel support for a.out and ECOFF binaries (OBSOLETE) depends on X86_32 || ALPHA || ARM || M68K || SPARC32 ---help--- A.out (Assembler.OUTput) is a set of formats for libraries and Plusminus depends on EMBEDDED to already hide it in the short term until removal. (Yes, ideally, one would use the yet-to-be-introduced CONFIG_OBSOLETE) Jan -- - 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: Examine user space locks
On Aug 1 2007 22:07, Rokas Masiulis wrote: sometimes user space program hangs forever. In old days i remeber there was unkillable dosemu. May be there are good how to. Some one can point to it? This is problem/solution isn't related to current kernel. This is question: what to do in this sitaution. echo t /proc/sysrq-trigger to generate stack traces of all processes, and then look it up in the kernel log. Jan -- - 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: VIA EPIA EK: strange eth dev numbering
On Aug 2 2007 12:42, Herbert Rosmanith wrote: hu. where are the days when eth0 was eth0 ... If you and/or your distribution accidentally or incidentally loaded modules in the wrong order (which may happen in e.g. parallel-running boot scripts), you suddenly have eth0 as eth1. Or, when you changed the PCI slots (i.e. swapped cards around), eth0 would also suddenly become a different one. There never *were* days when eth0 remained eth0 across such changes. which translates: Haha, that's randy, that's like in Windows, which notices that you've got a new mainboard In Linux, the user recognizes he got himself a new mainboard, e.g. when the IDE chip changed and the new module is not in the initrd. Jan -- - 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: VIA EPIA EK: strange eth dev numbering
On Aug 2 2007 12:20, Herbert Rosmanith wrote: I see a strange numbering of ethernet devices with a VIA EPIA EK board. This board has two ethernet connectors, you can see it here: http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=420 Maybe udev is configured to do renaming on the interfaces? an ifconfig eth0(eth1) will report: Hence use `ip a`. pretty strange?! I dont think this is the correct behaviour, is it? No, not strange at all. At least openSUSE ensures (or TRIES - there are _really_ broken chips out there that change their MAC every boot) that each card has the same interface name regardless of load order etc. Jan -- - 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: renaming kernel devices [was: VIA EPIA EK: strange eth dev numbering]
On Aug 2 2007 15:23, Michael Tokarev wrote: Herbert Rosmanith wrote: On Aug 2 2007 12:42, Herbert Rosmanith wrote: There never *were* days when eth0 remained eth0 across such changes. [] of course, that's problem with gentoo, not with the kernel. To me it'd be a problem, but I don't run udev (more, I hate udev ;) By the way, this very approach (renaming new eth0 interface to the next free ethX) seems to be flawed. It does not rename ethX to the next free one, but to a _persistent_ one. If it were a next free thing, then removing a card would shuffle all your eth around again (and invalidate your iptables rules at the same time, to note). first of all, I'd turn this behaviour off by default, but only when the user asked me to do so - say, when a new NIC is found, ask a user what's the name he wants it to be known as. *Or* choosed different basename for the renamed devices. So that in-kernel eth0 becomes, say, nicX instead of ethX - to make things explicit. Current way is just too confusing, when eth0 quietly becomes eth2 or whatnot. Remember that persistent names also need to provide means for hot-pluggable devices. Say your eth0 was a wireless, then you surely would _not ever_ want that on removal of eth0, all other cards step one down (eth1,eth2,ethN-eth0,eth1,ethN-1). Unfortuantely, I think it is hard (if not that, then it's a lot of code) to distinguish coldplugged vs hotplugged devices. And second half, which is more important here, is to always keep kernel names, and create aliases named by user (or automatic nicX scheme). This is fundamental -- applies to every device on the system. This is easy. Edit /lib/udev/rename_netiface to always hand out nicX regardless of whether the input device was ethX, trX, raX, wlanX or whatever. For example, if kernel says it has disk named sda, it should be accessible as /dev/sda (and /sys/block/sda, whatever), Note that /dev/sda is not persistent either. and any alternative names (boot disk, disk-serial-12345 etc yadda) should be symlinks in /dev. Ie, general rule is to remove *ALL* NAME statements from udev.conf file and use SYMLINK instead. See above - make rename_netiface use nicX. (Symlinks don't exist for netdevices.) For network interfaces, ifconfig -a may omit the kernel names from the listing (but in this case, say, ifconfig -aa should still show them), or alternatively it may show something like (ifconfig has been superseded by iproute2, please use it :) eth0 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX Name nic10 ^^ and both ifconfig eth0 blablabla and ifconfig nic10 blablabla will work identically. I prefer nic10 directly over having a dual. You'd be totally lost of syslog showed eth0 (from klog) and nic10 (from userspace). I already can see comments from udev/sysfs maintainers here: naming is a policy which does not belong to kernel. It's a bullshit, because kernel too has to use SOME way to name things, (1) The kernel starts with ethX (2) udev renames it to something else (3) kernel uses new name too (ni0: link down) and either we should teach it to use our names EVERYWHERE (including early-boot printk()), or accept the fact that any userspace naming (the policy) should be implemented as aliases for kernel names, not as renames. (And no, things like I/O error on SCSI device 8:32 sector XXX is even worse - I don't want to care which numbers are used for the devices, I want to see which sdX it is). Jan -- - 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: VIA EPIA EK: strange eth dev numbering
On Aug 2 2007 12:56, Herbert Rosmanith wrote: On Aug 2 2007 12:42, Herbert Rosmanith wrote: There never *were* days when eth0 remained eth0 across such changes. but there *were* days when eth0 was eth0, if the kernel reports it as such. now there is no eth0 at all. if I see an eth0 from dmesg, I expect it to be present. Wait, you forget that something may change the name. That dmesg message from 1 second ago does not need to be valid anymore, just as anything else in this world. On Aug 2 2007 13:12, Herbert Rosmanith wrote: cards around), eth0 would also suddenly become a different one. There never *were* days when eth0 remained eth0 across such changes. but there *were* days when eth0 was eth0, if the kernel reports it as such. now there is no eth0 at all. if I see an eth0 from dmesg, I expect it to be present. hm, well, a thought, maybe udev should report what is doing, like printinig renamed eth0 to eth2, or such. I think it once did with suse, but it does not right now. Worth fixing (yet I am no udev maintainer). the problem with this device renaming in my case was that other software, in particular dhcpcd, didnt get any lease, because (obviously?) dhcpcd on the other hand _still_ seemed to look for eth0, and thus, after booting, there was no network configured at all. So blame your distro for not integrating udev correctly with dhcp-client. I can only speak for suse, where you define BOOTPROTO=dhcp for an interface. Then, on /etc/init.d/network, every interface that has a configuration file gets run, so you never see what ethX udev picked for the day, but things still work. That's good^TM. Jan -- - 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] type safe allocator
On Aug 2 2007 16:04, Alexey Dobriyan wrote: On 8/2/07, Miklos Szeredi [EMAIL PROTECTED] wrote: fooptr = kmalloc(sizeof(struct foo), ...); Key word is traditional. Good traditional form which even half-competent C programmers immediately parse in retina. And being aware of the potential type-unsafety makes programmers more careful IMHO. +/** + * alloc_struct - allocate given type object + * @type: the type of the object to allocate + * @flags: the type of memory to allocate. + */ +#define alloc_struct(type, flags) ((type *) kmalloc(sizeof(type), flags)) someone will write alloc_struct(int, GFP_KERNEL), I promise. and someone else will write struct complexthing foo; alloc_struct(foo, GFP_KERNEL); Jan -- - 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: VIA EPIA EK: strange eth dev numbering
On Aug 2 2007 14:00, Herbert Rosmanith wrote: Wait, you forget that something may change the name. That dmesg message from 1 second ago does not need to be valid anymore, just as anything else in this world. there are many things in this world which are usually very persistent, and people rely on their persistence. e.g. in my office, I assume the phone number is still the same I used 1 second ago ... but what has this to do with ethernet device names? well: I expected the names persist - like they did without udev. I'm used that things persist, as probably the rest of the world :-) Yes, your telephone number persists even if you plug it into another jack (well, at least for my ISDN box, this holds true). Your names did persist - no card uses eth0 (which seems to belong to another one that is not currently installed). Note also that not the names per se are persistent, the (name,device) tuples are. Jan -- - 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] type safe allocator
On Aug 2 2007 15:06, Miklos Szeredi wrote: On Aug 2 2007 16:04, Alexey Dobriyan wrote: On 8/2/07, Miklos Szeredi [EMAIL PROTECTED] wrote: fooptr = kmalloc(sizeof(struct foo), ...); Key word is traditional. Good traditional form which even half-competent C programmers immediately parse in retina. And being aware of the potential type-unsafety makes programmers more careful IMHO. That's a _really_ good reason ;) Yes, a good reason not to use g_new(), so people do get bitten when they are doingitwrong. Jan -- - 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: renaming kernel devices [was: VIA EPIA EK: strange eth dev numbering]
On Aug 2 2007 16:56, Michael Tokarev wrote: I already can see comments from udev/sysfs maintainers here: naming is a policy which does not belong to kernel. It's a bullshit, because kernel too has to use SOME way to name things, (1) The kernel starts with ethX (2) udev renames it to something else (3) kernel uses new name too (ni0: link down) And now tell me please how can I connect two messages from dmesg: eth0: Tigon3 [partno(BCM95721) rev 4201 PHY(5750)] (PCI Express) 10/100/1000Base-T Ethernet 00:14:5e:5d:18:26 nic10: Link is up at 100 Mbps, full duplex. Generally, the link is xyz message comes directly after loading the module, so it should be eth0 before udev gets a chance to rename it. Or maybe not - in which case, well, you're literally fubared, and your distro should put a renamed A to B into syslog. What I wanted to say (here with network devices, and with disk names and everything else) is -- as long as the device is here (plugged in but not yet unplugged), I want it to have the same primary name in kernel and in userspace, so that everything Oh I think it already has a primary name today -- $ readlink /sys/class/net/eth0/device ../../../../../devices/pci:00/:00:04.0 there is your primary name, and your secondary name is ethZ. :) Jan -- - 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: VIA EPIA EK: strange eth dev numbering
On Aug 2 2007 17:07, Michael Tokarev wrote: Jan Engelhardt wrote: On Aug 2 2007 12:56, Herbert Rosmanith wrote: On Aug 2 2007 12:42, Herbert Rosmanith wrote: There never *were* days when eth0 remained eth0 across such changes. but there *were* days when eth0 was eth0, if the kernel reports it as such. now there is no eth0 at all. if I see an eth0 from dmesg, I expect it to be present. Wait, you forget that something may change the name. That dmesg message from 1 second ago does not need to be valid anymore, just as anything else in this world. That was my argument - there should be no way to *change* the name, but to give an alias(es) - entirely different thing. Ah, in that case, make the kernel print the PCI-ID instead of the name. (Or perhaps both together.) As for userspace, you are free to do whatever you find most useful. Jan -- - 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] type safe allocator
On Aug 2 2007 16:06, Bernd Petrovitsch wrote: thrice in some cases like alloc_struct(struct task_struct, GFP_KERNEL) Save the explicit struct and put it into the macro (and force people to not use typedefs). #define alloc_struct(type, flags) ((type *)kmalloc(sizeof(struct type), (flags))) #define alloc_struct(type, flags) ((struct type *)kmalloc(sizeof(struct type), (flags))) Obious drawback: We may need alloc_union(). SCNR. And we still don't have something to allocate a bunch of ints. [kmalloc(sizeof(int)*5,GFP)] Jan -- - 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/
nf_conntrack_ipv4 must be loaded explicitly
Hi, in recent git kernels, I experience the following regression that no packets traverse the nat table (esp. the POSTROUTING counters just stand still) - and hence things like ping+SNAT do not work. Bisect nailed it down to: ff09b7493c8f433d3ffd6a31ad58d190f82ef0c5 is first bad commit commit ff09b7493c8f433d3ffd6a31ad58d190f82ef0c5 Author: Yasuyuki Kozakai [EMAIL PROTECTED] Date: Sat Jul 7 22:25:28 2007 -0700 [NETFILTER]: nf_nat: remove unused nf_nat_module_is_loaded Signed-off-by: Yasuyuki Kozakai [EMAIL PROTECTED] Signed-off-by: Patrick McHardy [EMAIL PROTECTED] Signed-off-by: David S. Miller [EMAIL PROTECTED] :04 04 177886eca60385293ac736c8e4861a2d4910d90a 32e63b6a9399e1ea65dc6cd0b357ca811e4dc835 M include :04 04 e1c20c3db28c927af62df067b2a20f8604a5fe06 84a277d1f81e3be9ce37ce6040c6d814ca20b3b0 M net The diff from ff09b7^...ff09b7 made me think... End result: After loading nf_conntrack_ipv4.ko, everything works again (also with the bad ff09b7). But I have to load it explicitly, and I think that unfortunately breaks a lot of setups (such as mine) which assume ipv4 connection tracking is always there. Comments? Jan -- - 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: VIA EPIA EK: strange eth dev numbering
Hey,
I know I have seen my kernel outputting A renamed to B. Since you two
however wanted that information in the first place, I grepped a bit
around, and actually found, (drumroll), that the SUSE kernel has had a
proper patch for [I can't remember how long] quite some time. (At least
one distro which does the right thing.) I copied it below.
Jan
===
Name: patches.suse/nameif-track-rename.patch
Subject: [PATCH] keep track of network interface renaming
From: Olaf Hering [EMAIL PROTECTED]
Keep track about which network interface names were renamed after the
network device driver printed its banner. Example insanity:
honeydew:~ # dmesg| grep -Ew '(eth[0-9]|rename|renamed)'
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection
dev_change_name: about to rename 'eth3' to 'eth0'
dev_change_name: about to rename 'eth3' to 'ethxx3'
eth3 renamed to ethxx3
dev_change_name: about to rename 'ethxx3' to 'eth0'
dev_change_name: about to rename 'eth0' to 'eth3'
eth0 renamed to eth3
dev_change_name: about to rename 'eth1' to 'eth2'
dev_change_name: about to rename 'eth1' to 'ethxx1'
eth1 renamed to ethxx1
dev_change_name: about to rename 'ethxx1' to 'eth2'
dev_change_name: about to rename 'eth2' to 'eth1'
eth2 renamed to eth1
dev_change_name: about to rename 'ethxx3' to 'eth0'
ethxx3 renamed to eth0
dev_change_name: about to rename 'ethxx1' to 'eth2'
ethxx1 renamed to eth2
e1000: eth0: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex
Signed-off-by: Olaf Hering [EMAIL PROTECTED]
net/core/dev.c |4
1 files changed, 4 insertions(+)
--- linux-2.6.21.orig/net/core/dev.c
+++ linux-2.6.21/net/core/dev.c
@@ -822,7 +822,11 @@ int dev_change_name(struct net_device *d
else if (__dev_get_by_name(newname))
return -EEXIST;
else
+ {
+ if (strncmp(newname, dev-name, IFNAMSIZ))
+ printk(KERN_INFO %s renamed to %s\n, dev-name,
newname);
strlcpy(dev-name, newname, IFNAMSIZ);
+ }
device_rename(dev-dev, dev-name);
hlist_del(dev-name_hlist);
-
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: gcc fixed size char array initialization bug - known?
On Aug 2 2007 21:55, Guennadi Liakhovetski wrote:
Hi
I've run across the following gcc feature:
char c[4] = 01234;
gcc emits a nice warning
warning: initializer-string for array of chars is too long
But do a
char c[4] = 0123;
and - a wonder - no warning. No warning with gcc 3.3.2, 3.3.5, 3.4.5,
4.1.2. I was told 4.2.x does produce a warning. Now do a
struct {
char c[4];
int i;
} t;
t.i = 0x12345678;
strcpy(t.c, c);
and t.i is silently corrupted. Just wanted to ask if this is known,
really...
What does this have to do with the kernel? The string 0123 is
generally _five_ characters long, so c[4] is not enough.
Or use strncpy.
Jan
--
-
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: gcc fixed size char array initialization bug - known?
On Aug 2 2007 21:55, Guennadi Liakhovetski wrote: Hi I've run across the following gcc feature: char c[4] = 01234; gcc emits a nice warning warning: initializer-string for array of chars is too long But do a char c[4] = 0123; and - a wonder - no warning. No warning with gcc 3.3.2, 3.3.5, 3.4.5, 4.1.2. I was told 4.2.x does produce a warning. Now do a Unfortunately, gcc 4.2.1 does not produce a warning for char a[4] = haha; Jan -- - 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: VIA EPIA EK: strange eth dev numbering
On Aug 3 2007 00:00, Kay Sievers wrote: On 8/2/07, Jan Engelhardt [EMAIL PROTECTED] wrote: I know I have seen my kernel outputting A renamed to B. Since you two however wanted that information in the first place, I grepped a bit around, and actually found, (drumroll), that the SUSE kernel has had a proper patch for [I can't remember how long] quite some time. (At least one distro which does the right thing.) I copied it below. e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection dev_change_name: about to rename 'eth3' to 'eth0' dev_change_name: about to rename 'eth3' to 'ethxx3' eth3 renamed to ethxx3 I just made udev when it successfully renamed an interface to write that to the kernel log, so dmesg will show: 6udev: renamed network interface eth0 to eth1 I think it is helpful to integrate the suse patch rather than to patch udev alone. This way, renames that do not involve udev also show up. Jan -- - 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: gcc fixed size char array initialization bug - known?
On Aug 3 2007 01:30, Guennadi Liakhovetski wrote: On Fri, 3 Aug 2007, Al Viro wrote: It doesn't change the fact that use of c[4] or strlen(c) or strcpy(..., c) means nasal demon country for you. Haha, funny. You, certainly, may think whatever you want, I'm anyway greatful to you and to all the rest for the trouble you took to find THE quote that actually answers the question. So back to the topic - if you want to check whether the kernel 'accidentally' uses char foo[4] = abcd; change gcc or sparse to warn about this and then sort out the pieces which are good. :) Jan -- - 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/
