Ping-Pong, the lists are dead?
I haven't received any emails from any vger lists since Jan. 29. Do they still work? Would anyone who gets this message please email "[EMAIL PROTECTED]" to let me know if my message gets to the list? I have to figure out why I can't see anything *from* the list... - 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/
Why does everyone hate gcc 2.95?
What does everyone have against gcc 2.95 on this list? I've been compiling kernels successfully (read: not one single (ever) error in compilation) with gcc 2.95.2 for more than a year now. What's the big deal? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch -mm 1/1] remove useless tolower in isofs
> Hi,
> Remove useless tolower in isofs
>
> Signed-off-by: dave young <[EMAIL PROTECTED]>
>
> inode.c |2 +-
> 1 file changed, 1 insertions(+), 1 deletions(-)
>
> diff -dur linux/fs/isofs/inode.c linux.new/fs/isofs/inode.c
> --- linux/fs/isofs/inode.c 2007-05-28 08:54:33.0 +
> +++ linux.new/fs/isofs/inode.c 2007-05-28 08:55:02.0 +
> @@ -197,7 +197,7 @@
>hash = init_name_hash();
>while (len--) {
>c = tolower(*name++);
> - hash = partial_name_hash(tolower(c), hash);
> + hash = partial_name_hash(c, hash);
>}
>qstr->hash = end_name_hash(hash);
How about this? A lot more readable and doesn't even need an intermediate
value.
for (; len; len--, name++) {
hash = partial_name_hash(tolower(*name), hash);
}
Or if you don't think that way is more readable, how about this?
while (len) {
hash = partial_name_hash(tolower(*name), hash);
name++;
len--;
}
And then there's the supercompact form.
while (len--) {
hash = partial_name_hash(tolower(*name++), hash);
}
But I do not like the last one at all. The first one is the best, because
it clearly separates the condition and iteration parts of the expression,
while STILL being only three lines long. Or two, if you omit the braces.
(But you shouldn't.)
-
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: stuff ready to be deleted?
> > i'm trying to keep track of kernel janitor projects that involve > > removing dead content from the tree: > > > > http://fsdev.net/wiki/index.php?title=Kernel_Janitor%27s_Todo_List > > > > currently, the list contains the items: > > > > * 1 Legacy power management > > * 2 PCMCIA IOCTL support > > * 3 Traffic shaper > > * 4 Traffic policing > > * 5 Userspace queueing via NETLINK > > * 6 ebt: ulog support > > * 7 MOXA SmartIO support > > * 8 Old I2O ioctls > > * 9 Stallion drivers > > * 10 SDL RISCom/8 support > > * 11 Macintosh M68K support > > * 12 Commodore A2232 serial support > > * 13 CONFIG_FORCED_INLINING > > * 14 kernel_thread() > > > > which of the above are legitimate candidates for removal? which are > > already underway in someone's local tree? anything else that can > > be added? etc, etc. > > > > Take a look at Documentation/feature-removal-schedule.txt > Some of that stuff is already listed there along with who is in charge > of removing it and when. Let's not get in that catfight again. That file has been demonstrated to be half too premature and half completely obsolete. He's asking for which things should he start generating and sending patches and expect them to not be ignored or angrily shot down. feature-removal-schedule.txt does not provide this information, again as has been demonstrated. Of course, it would be great if it were accurate and -did- provide that information. - 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 1/1] document Acked-by:
> >> +If a person was not directly involved in the preparation or handling of a > >> +patch but wishes to signify and record their approval of it then they can > >> +arrange to have an Acked-by: line added to the patch's changelog. > >> + > >> +Acked-by: is often used by the maintainer of the affected code when that > >> +maintainer neither wrote, merged nor forwarded the patch themselves. > > > > Do we want to add verbiage saying that an Acked-By: is also useful when it > > comes from somebody (likely the original reporter) who has actually tested > > the > > patch? > > I'd rather see a Tested-By: for that. > > There is a difference between a maintainer ack and a tester ok. Indeed. Acked-by: implies authority, and only very few people should be able to do it. Namely, the only person who can ACK a patch is a person who could also NACK a patch and expect it to actually be dropped. If I think a patch is bad, I can say so, but as I have no authority, my statement would be taken on merit alone, whereas Linus or Andrew or such could just NACK it and move on without having to spew a blurb every time. - 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 1/1] document Acked-by:
> > I think the comment had to do with the concept that ACK/NAK implies > > authority. If you're not the maintainer, it's rude to imply that you > > are. Obvious, test reports (good or bad!) are always welcome. > > Well, I understand a test is a different thing, an experiment to > see if the patch works or not, while ack/etc. is just opinion > of someone who reads the patch without actually using it. > > I think ack/etc doesn't, in any way, imply being the maintainer, > though it imply that the "acker" has actually read the code, > understands it, and believes it's correct (or not, and why). > > If we want to differentiate between "authoritative" and > "non-authoritative" opinions (and the name and email address > aren't enough) then I think we need to state that explicite > (perhaps something like "Acked-by: FIRST M. LAST , XXX > subsystem maintainer" would suffice). "Acked-by:" does not mean "I like this" but rather "I approve of this". Someone who is not a maintainer is encouraged to speak of like and dislike, in great detail, but has no position at all to approve or disapprove of it going in. If I put "Acked-by: John..." on a patch of any kind, even trivial, it would look incredibly stupid, because I'm just some guy messing around with the kernel. A tactful response to me doing that from any actual kernel bigwig would be, "I appreciate your enthusiasm, but you are not part of the kernel patch flow." Similarly, a tactful response to me NACKing a patch would be, "I appreciate your concern, but you are in no position to remove a patch from the stream. Your comments will be considered and implemented or countered by an actual maintainer." This is appropriate. - 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: SLUB: Return ZERO_SIZE_PTR for kmalloc(0)
> + * The behavior for zero sized allocs changes. We no longer > + * allocate memory but return ZERO_SIZE_PTR. > + * WARN so that people can review and fix their code. I don't see why people have so much opposition to zero-size memory allocations. There's all sorts of situations where you want a resizeable array that may have zero objects, especially in these days of hotpluggability. Not only is it simpler (and therefore less likely to be buggy) to write code to simply resize to current number of objects, but not having to make additional code for checking the special case of count==0 leading to different function calls (instead of always reallocating, you might have to allocate instead, and instead of reallocating to zero you might have to free instead) will very slightly increase the object-text size. The standard-C behavior of valid zero-size allocation has a very good 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: SLUB: Return ZERO_SIZE_PTR for kmalloc(0)
> > > + * The behavior for zero sized allocs changes. We no longer > > > + * allocate memory but return ZERO_SIZE_PTR. > > > + * WARN so that people can review and fix their code. > > > > I don't see why people have so much opposition to zero-size memory > > allocations. There's all sorts of situations where you want a resizeable > > array that may have zero objects, especially in these days of > > hotpluggability. > > In case you have not read the description to the end: This patch does > exactly what you want and legitimizes zero size object use. The warning > will be remove before 2.6.22 is released. Ah, sorry then. I just saw this, and remembered a rather contrary discussion about it quite a time ago. Excellent then. - 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 1/1] document Acked-by:
> > > > > Explain what we use Acked-by: for, and how it differs from > > > > Signed-off-by: > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > > > + > > > > > +If a person was not directly involved in the preparation or > > > > handling of a > > > > > +patch but wishes to signify and record their approval of it then > > > > they can > > > > > +arrange to have an Acked-by: line added to the patch's changelog. > > > > > > > > Acked-by: Dave Jones <[EMAIL PROTECTED]> > > > > > > What, no Tested-by: ? > > > >Heh. Indeed. I think there's room for both fwiw. > > Too verbose. Suggest a typedef. > > Signed-off-and-tested-by: Foo J. Bar <[EMAIL PROTECTED]> Signed-off-by: should imply Tested-by:, with the exception of the final Signed-off-by: when it's merged into a tree. Tested-by:, if it really is necessary or useful, should be reserved for only those who test something but weren't involved in its development. Adding it to the tag is unnecessary unless somebody thinks there's a serious problem with untested patches being introduced by first-hand maintainers that a forced reminder would remedy. - 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: Long file names in VFAT broken with iocharset=utf8
> >Just because you limit yourself to 80 chars minus "ls -l"-clutter, this is > >no reason why I shouldn't use long filenames. If I need to handle these > >filenames, I can enlarge the terminal window or read the next line. > > > >E.g.: I have a music file named "artist - title.ext", where the artist > >name is 103 characters long, using abbreviations. In order to enter that > >name, I have to press seven keys, including the escape character. > >There is nothing unreasonable in using that name. > > What name would that be? I cannot dream up any IME that outputs _that_ > many characters for that few keystrokes. Even with CJ(K), 7 keystrokes can > make at most 21 bytes if I had to take a good guess. Probably talking about tab-completion in the shell, countering the comment that names that long are too unwieldy to use. On the other hand, limits are always bad. Haven't we seen bajillions of cases in computing history where we start with limits (like only N of the first characters of identifiers used in compilers), followed by people finding those limits annoying, then followed by the limits being removed? How about the Year-20?? limitations? Same thing: limits that were fine, then limits were not fine, then limits were removed. In this era, couldn't we just skip the whole thing and stop putting limits in from the beginning? The only reason to have a PATH_MAX/NAME_MAX at all is to make life easier for programmers implementing things and people using things. It would require a LOT of work and changes, but life would be so much better if there were a (configurable, of course!) option to say "use standard values" or "use custom values" or "use runtime-dynamic values". Option 1: No change. Option 2: Alter your limits.h too, and recompile programs (or fix them). Option 3: Change programs from compile-time inclusion of limits.h to run-time checking of a /sys value. - 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] module_author: don't advice putting in an email address
> > The email address is the problem I was trying to fix; with multiple current > > and non-current authors and maintainers who might not even be authors the > > address(es) available from the tag confuse the issue of whom to contact. > > It's moreover also information that easily outdated. > > > > A bit more than half of the tags in the tree don't include an email address > > already and I'll submit patches removing more... > > Please don't do this > > NACK this change. > > Whether someone puts their email address into the entry is their own > business. We do not need a style police for module author entries. > > At most you might want to put > > "If you include an email address then please use an address that >you expect to keep for the long term, and if you change address >please remember to update or remove the entry" > > > A bit more than half of the tags in the tree don't include an email > > address already and I'll submit patches removing more... > > And I'll NAK every one which hasn't been signed off by the email address > listed OR the address bounces. In which case removing it is good. Can't we just subtitle it somehow? Add tags: " (current maintainer)", " (original author, inactive)", " (bug and defect reports)", or whatever you like after the names. - 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] Convert files to UTF-8 and some cleanups
> Marcin Garski wrote: > > Content-Type: application/octet-stream; > > name="linux-2.6.22-rc1-utf-8-strings.patch.bz2" > > Content-Transfer-Encoding: base64 > > Content-Disposition: attachment; > > filename="linux-2.6.22-rc1-utf-8-strings.patch.bz2" > > > > QlpoOTFBWSZTWSc/F00Ahxp/v///itd///8QQO6yN0QYAABArrIlRGBofng9 > > APLeSe3t9HBeePnl0PJwG73R777qguxoH3sAPfYaKB0BwABdbe4C9nRevqU6lwXTg8De > > It's customary to post in plain text. Best is inline plain text. Thanks, You can't post a patch to UTF-8 in plain text, because it isn't plain text. MTAs and MUAs mangle the hell out of them. Look back in the archives for my postings. Once you've got something in UTF-8, -*THEN*- you can post in plain inline text. - 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: SLUB: Return ZERO_SIZE_PTR for kmalloc(0)
> > Here a version of the patch that drops the WARN_ONs > > And now all that's done, how about yet another random person stepping in and > suggesting NIL or maybe NIL_PTR instead of ZERO_SIZE_PTR? > > I understand the idea is that code need not necesarily care about zero sized > allocation meaning it won't (generally) need to spell it out but it's still a > dreadful name... :-( The name says exactly what it is. It's not at all dreadful. If we're going to return a special value in the zero-size case (and in only that case) as a valid pointer instead of actually allocating one byte and treating it as zero, what we have is...a zero-size pointer. ZERO_SIZE_PTR is a pretty damn good name. - 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: SLUB: Return ZERO_SIZE_PTR for kmalloc(0)
> > The name says exactly what it is. It's not at all dreadful. If we're going > > to return a special value in the zero-size case (and in only that case) as a > > valid pointer instead of actually allocating one byte and treating it as > > zero, what we have is...a zero-size pointer. > > No, what we have is a sizeof(pointer) sized pointer pointing to an object of > size zero. ZERO_SIZE_PTR is butt-ugly. With a really ugly butt. sizeof(pointer) is the object. ZERO_SIZE_PTR is the value stored in that object. Would you prefer PTR_TO_ZERO_SIZE_OBJ_VAL? Maybe you would prefer ZERO_SIZE_OBJ instead. What you have is "a pointer object which points to a zero-sized object". What if there were some construct in the kernel that never got deleted? We'll call it "struct foo * bar_ctl". What would you call a pointer to this? "bar_ctl_ptr". Or even "foo_ptr". So "ZERO_SIZE_OBJ_PTR" is the most correct form, and "ZERO_SIZE_PTR" is a convenient shortening. "ZERO_PTR" is too short and also confuses with NULL because NULL is a zero-value object, rather than a non-zero--value pointer to a zero-size object. - 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 (a bug?) with UINT_MAX from kernel.h
> The kernel uses UINT_MAX defined from kernel.h in a variety of places. > > While looking at the behaviour of the LZO code, I noticed it seemed to > think an int was 8 bytes large on my 32 bit i386 machine. It isn't but > why did it think that? > > kernel.h says: > > #define INT_MAX ((int)(~0U>>1)) > #define INT_MIN (-INT_MAX - 1) > #define UINT_MAX (~0U) > #define LONG_MAX ((long)(~0UL>>1)) > #define LONG_MIN (-LONG_MAX - 1) > #define ULONG_MAX (~0UL) > #define LLONG_MAX ((long long)(~0ULL>>1)) > #define LLONG_MIN (-LLONG_MAX - 1) > #define ULLONG_MAX(~0ULL) > > If I try to compile the code fragment below, I see the error: > > #define UINT_MAX (~0U) > #if (0x == UINT_MAX) > #error argh > #endif > > I've tested this on several systems with a variety of gcc versions with > the same result. I've tried various other ways of testing this all with > the same conclusion, UINT_MAX is wrong. > > The *LONG* definitions above should work as gcc is forced to a certain > type. Where just 0U is specified, I don't think it will work as intended > as gcc seems to automatically increase the type to fit the value and > avoid truncation ending up with a long long. > > If I change the above to: > > /* Handle GCC = 3.2 */ > #if !defined(__INT_MAX__) > #define INT_MAX 0x7fff > #else > #define INT_MAX (__INT_MAX__) > #endif > #define INT_MIN (-INT_MAX - 1) > #define UINT_MAX ((INT_MAX<<1)+1) For one thing, the C standard specifies that literals fit into signed before unsigned if they're not specified as unsigned in the first place. Shifting signed values (INT_MAX<<1) is wrong on some architectures and foolish on all. You would have to do "(unsigned int)INT_MAX << 1". > I get the expected result of an int being 4 bytes long. Is there a > better solution? Its probably better that whats there now but could > break a machine using gcc 3.2 that doesn't have int size = 4 bytes... > > (gcc <= 3.2 doesn't define __INT_MAX__) The C standard specifies that a numeric literal constant ending with "U" may be interpreted as unsigned int, unsigned long int, or unsigned long long int, in that order, choosing the first in which it will fit. So "~0U" is correct. If it's not working, I suggest you file a compiler bug/defect report. - 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] ubi: kill homegrown endian macros
On Fri, 18 May 2007, David Woodhouse wrote: > On Thu, 2007-05-17 at 20:30 +, Matthieu CASTET wrote: > > On Thu, 17 May 2007 10:29:31 -0700, Andrew Morton wrote: > > > > > On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy > > > <[EMAIL PROTECTED]> wrote: > > > > > > umm.. I'd say what you've done in there is an improvement to the > > > exiting stuff: getting gcc to check it is better than having to use > > > sparse. > > > > > > I'd have expected gcc to generate poorer code with your approach but I'm > > > showing zero text size changes from Christoph's patch (gcc-4.1 and > > > gcc-3.4.5). > > > > > > > > On which arch did you try ? > > X86 where unaligned access are ok ? > > > > On arch that don't support aligned access, packed struct access will be > > done byte per byte (but it could be the expected behavior if there > > unaligned access). > > When I tested this on ARM, the output for je32_to_cpu et al was fine. > For _other_ structures where I'd used __attribute__((packed)) to be > safe, gcc would emit code to handle unaligned loads. But not in the > simple case where the struct has only one member. > > Are you suggesting that this has changed since I did my testing? Wouldn't the appropriate test be to demonstrate that the same program text opcodes are generated in both cases for all architectures? If that's not the case, even if the generation isn't -worse-, it shows that the compiler is doing different things with each, which means different versions of the compiler could do different things with it, and all of a sudden another nice programming construct which helps compile-time issues ends up increasing the number of cases where compiler differences generate faster or slower kernels with the same code, whereas in the test cases it was "no better, no worse" so deemed fine. - 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] ubi: kill homegrown endian macros
On Fri, 18 May 2007, David Woodhouse wrote: > On Thu, 2007-05-17 at 22:57 -0400, John Anthony Kazos Jr. wrote: > > Wouldn't the appropriate test be to demonstrate that the same program text > > opcodes are generated in both cases for all architectures? > > No, empirical testing with the compiler is never the _correct_ thing to > do. It's just expedient. > > > If that's not the case, even if the generation isn't -worse-, it shows > > that the compiler is doing different things with each, which means > > different versions of the compiler could do different things with it, > > Well yes, but even it _is_ generating precisely the same output today, > there's no reason why the compiler shouldn't behave differently under a > different phase of the moon. > > The _correct_ thing to do is act upon my mutterings at the time I > removed the '__attribute__((packed))' from various JFFS2 structures to > improve the generated code on ARM -- actually implement an attribute for > GCC which has the same "don't insert any padding" meaning, but without > the unwanted "assume arbitrary alignment" implications. Out of curiosity, why would a compiler ever insert padding in a structure that has all its elements properly-aligned? > It'd actually be nice if GCC knew about endianness too. I don't want to > have to do: > >*x = le32_to_cpu(cpu_to_le32(*x) + 5); > > I just want > > uint32_t __attribute__((littleendian)) *x; > > *x += 5; > > I know we can hack around it for masks, with '*x |= cpu_to_le32(X_BAR);' > and such like, and we can load it into local native-endian variables and > then copy it back again later -- but it's better just to let the > compiler know what's going on and do its own optimisation. Especially on > architectures which have 'load-and-swap' or 'store-and-swap' > instructions. - 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: any value to "NORET_TYPE" macro?
> given that:
>
> $ grep -r "define.*NORET_TYPE" *
> include/linux/ext4_fs.h:# define NORET_TYPE/**/
> include/linux/linkage.h:#define NORET_TYPE/**/
> include/linux/ext3_fs.h:# define NORET_TYPE/**/
> $
>
> is there any obvious value to the 30 or so uses of that macro
> sprinkled throughout the tree?
Since it evaluates to absolutely empty code during pre-processing, there
is no obvious value. The question is whether there is some odd hackish
non-obvious value, I'd expect. (I'd also expect that to be another "no".)
If something that evaluates to nothingness ("There was nothing left...not
even a hole!") actually does anything, then somebody in the
standards-compilers-users pipeline needs to be violently beaten for
stupidity.
-
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: ZFS with Linux: An Open Plea
> FUSE implemtation uses too many context switches on each I/O so on the same > hardware it will never will be so fast as on Linux, BSD and MOX (yes ZFS is > now avalaible on all this OSes .. and few people says Windows implemtation is > very close). Current FUSE implemntation can't be comparable in aspects of > speed and probably never will be on using threads (very simmilar case to ALSA > and mixing in user space .. in both cases it is broken by design). Also ZFS on > Solaris uses few other system abilities for example it interract with PSH. > > So FUSE ZFS is IMO only kind of academic demo implemtation only but never will > be usefull/ready for production (plain waste of time). If Linux licensing will > not be relaxed probaly we can forget about ZFS on Linux (licensing problems in > this case are obly on Linux side .. in this case ZFS licensing is > more oppened than Linux licensing ). > > kloczek > PS. IIRC implemting ZFS on FUSE was some kind of workaround for licensing > issue but FUSE fill uses vfs layer and probaly still thinking about > licensing is actual. I'm just a lowly proto-hacker trying to get into kernel development, but even I know a few things, and I'm getting very tired of hearing FUSE slammed as stupid and the Linux licencing policy as foolish. I can sum things up in two short passages. FUSE is intended for end-users, not critical server applications. End-users have plenty of processor to spare at lower-than-ever prices. So you have a simple and flexible end-user API that lets you do anything with anything in any way you want, all the time, without needing to (or even needing to be able to) alter your kernel. Win. Linux licencing basically says, "If you want in on this good thing, you have to play by the rules. That means no cheating, no scamming, no profiting at the expense of others, and no getting on a high horse and proclaiming to the rest of the world that you are in control of their destinies. Play nice, kiddies." If you want to do something, you do it open and you do it Free, and if you don't want to, well...write your own kernel! There is a wonderful quotation on the GNU site comparing agencies like Microsoft to crack dealers: They appear more open in theory in order to get people hooked, then trigger the beartrap around your foot. Linux has rules--hard, fast, and immutable--and they protect everybody from their own stupidities. Open-community development takes a whole lot longer, but you don't have to sell your soul to do it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ZFS with Linux: An Open Plea
> And/or why Linux code licensing can't evolve ? Seems when Linux code was > licensed noone was thinking about case like interraction with code under > license like CDDL so why now it can be corrected and still many people try to > think like "anything arond Linux must evolve .. but not Linux" (?) > Why this can't be fixes ? That's not evolution; it's de-evolution. Linux morphing to some sort of mentally-damaged pseudo-proprietary licence would be like switching back to a feudal society where 50 was considered unbelievably ancient. I'm sure Linus did think very closely about the interaction of his code with proprietary licences. He thought about it, snickered for a few moments, and made the right decision. - 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: ZFS with Linux: An Open Plea
> > That's not evolution; it's de-evolution. Linux morphing to some sort of > > mentally-damaged pseudo-proprietary licence would be like switching back > > to a feudal society where 50 was considered unbelievably ancient. > > CDDL is OSI aproved. Did you realy want to say by above something like "CDDL > is pseudo-proprietary licence" ? Are you still taking about (and only) CDDL ? >From what I have read, CDDL is treading the vrry thin line between an actual Free license and an actual proprietary licence. Just look at the nonsense Mozilla Co. has gotten itself worked up about (and judging by how much Firefox/Iceweasel crashes on me, being like IE is quite appropriate in licencing too). And (if I have not been misinformed), CDDL is inspired by Mozilla's licence. The FSF has something to say. http://www.gnu.org/licenses/license-list.html#SoftwareLicenses So yes, CDDL is, to me, "pseudo-"proprietary, and it would be very easy for them to slip up and whoops! Didn't we tell you? You can do everything but -that-. But of course it's still free...yeah... > > I'm sure Linus did think very closely about the interaction of his code > > with proprietary licences. He thought about it, snickered for a few > > moments, and made the right decision. > > I don't want see problmes on border with propretary licenses at all but I see > (and still want to talk only about) problem on on some class licenses which > provides more oppened (and not closed) code. The GPL is more about protection than openness. Someone can write code, throw it on the internet with no licence at all, and it's exactly as "open" as it is under the GPL. You can do anything you want with it in any way, just like under the GPL. What the GPL does is protect the code and its writer from being snapped up by somebody else, and in any way restricted: It makes sure the code STAYS open, and makes sure you are always free to do as you like with it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] top of tree: convert CREDITS and MAINTAINERS to UTF-8
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]> Convert the toplevel files CREDITS and MAINTAINERS to UTF-8. Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]> --- I can't get my mail client to send in ISO-8859-1 instead of UTF-8, so the actual patch is attached in octet-stream format. The below patch is just for reference and will almost certainly NOT work. Also, since the patch includes both encodings, whichever encoding you select while viewing it will display one correct and one garbled line. However, the bytecodes -are- correct. diff -uprN linux-2.6.21-rc7.orig/CREDITS linux-2.6.21-rc7.mod/CREDITS --- linux-2.6.21-rc7.orig/CREDITS 2007-04-17 11:41:41.0 -0400 +++ linux-2.6.21-rc7.mod/CREDITS2007-04-17 11:53:29.0 -0400 @@ -374,7 +374,7 @@ S: FutureTV Labs Ltd S: Brunswick House, 61-69 Newmarket Rd, Cambridge CB5 8EG S: United Kingdom -N: Thomas Bogendörfer +N: Thomas Bogendörfer E: [EMAIL PROTECTED] D: PCnet32 driver, SONIC driver, JAZZ_ESP driver D: newport abscon driver, g364 framebuffer driver @@ -394,7 +394,7 @@ W: http://math-www.uni-paderborn.de/~axe D: Configuration help text support D: Linux CD and Support Giveaway List -N: Erik Inge Bolsø +N: Erik Inge Bolsø E: [EMAIL PROTECTED] D: Misc kernel hacks @@ -422,7 +422,7 @@ D: Various fixes (mostly networking) S: Montreal, Quebec S: Canada -N: Zoltán Böszörményi +N: Zoltán Böszörményi E: [EMAIL PROTECTED] D: MTRR emulation with Cyrix style ARR registers, Athlon MTRR support @@ -1023,11 +1023,11 @@ D: Future Domain TMC-16x0 SCSI driver (a D: APM driver (early port) D: DRM drivers (author of several) -N: János Farkas +N: János Farkas E: [EMAIL PROTECTED] D: romfs, various (mostly networking) fixes P: 1024/F81FB2E1 41 B7 E4 E6 3E D4 A6 71 6D 9C F3 9F F2 BF DF 6E -S: Madarász Viktor utca 25 +S: Madarász Viktor utca 25 S: 1131 Budapest S: Hungary @@ -1038,10 +1038,10 @@ D: UDF filesystem S: (ask for current address) S: USA -N: Jürgen Fischer +N: Jürgen Fischer E: [EMAIL PROTECTED] (=?iso-8859-1?q?J=FCrgen?= Fischer) D: Author of Adaptec AHA-152x SCSI driver -S: Schulstraße 18 +S: SchulstraÃe 18 S: 26506 Norden S: Germany @@ -1107,7 +1107,7 @@ E: [EMAIL PROTECTED] D: random kernel hacker, ZF MachZ Watchdog driver S: Conectiva S.A. S: R. Tocantins, 89 - Cristo Rei -S: 80050-430 - Curitiba - Paraná +S: 80050-430 - Curitiba - Paraná S: Brazil N: Kumar Gala @@ -1252,12 +1252,12 @@ S: 44 St. Joseph Street, Suite 506 S: Toronto, Ontario, M4Y 2W4 S: Canada -N: Richard Günther +N: Richard Günther E: [EMAIL PROTECTED] W: http://www.tat.physik.uni-tuebingen.de/~rguenth P: 2048/2E829319 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57 D: binfmt_misc -S: 72074 Tübingen +S: 72074 Tübingen S: Germany N: Justin Guyett @@ -1281,7 +1281,7 @@ N: Bruno Haible E: [EMAIL PROTECTED] D: SysV FS, shm swapping, memory management fixes S: 17 rue Danton -S: F - 94270 Le Kremlin-Bicêtre +S: F - 94270 Le Kremlin-Bicêtre S: France N: Greg Hankins @@ -1695,7 +1695,7 @@ S: Czech Republic N: Jakob Kemi E: [EMAIL PROTECTED] D: V4L W9966 Webcam driver -S: Forsbyvägen 33 +S: Forsbyvägen 33 S: 74143 Knivsta S: Sweden @@ -2058,7 +2058,7 @@ D: misc. kernel hacking and debugging S: Cambridge, MA 02139 S: USA -N: Martin von Löwis +N: Martin von Löwis E: [EMAIL PROTECTED] D: script binary format D: NTFS driver @@ -2135,7 +2135,7 @@ S: PO BOX 220, HFX. CENTRAL S: Halifax, Nova Scotia S: Canada B3J 3C8 -N: Kai Mäkisara +N: Kai Mäkisara E: [EMAIL PROTECTED] D: SCSI Tape Driver @@ -2293,7 +2293,7 @@ P: 1024D/9224DF01 D5DF E3BB E3C8 BCBB F8 D: IPX, LLC, DCCP, cyc2x, wl3501_cs, net/ hacks S: Mandriva S: R. Tocantins, 89 - Cristo Rei -S: 80050-430 - Curitiba - Paraná +S: 80050-430 - Curitiba - Paraná S: Brazil N: Karsten Merker @@ -2779,10 +2779,10 @@ N: Juan Quintela E: [EMAIL PROTECTED] D: Memory Management hacking S: LFCIA -S: Departamento de Computación -S: Universidade da Coruña +S: Departamento de Computación +S: Universidade da Coruña S: E-15071 -S: A Coruña +S: A Coruña S: Spain N: Augusto Cesar Radtke @@ -2933,7 +2933,7 @@ E: [EMAIL PROTECTED] D: Support for EtherExpress 10 ISA (i82595) in eepro driver D: User level driver support for input S: R. Jose Serrato, 130 - Santa Candida -S: 82640-320 - Curitiba - Paraná +S: 82640-320 - Curitiba - Paraná S: Brazil N: Alessandro Rubini @@ -3331,15 +3331,15 @@ P: 1024D/D0FE7AFB B24A 65C9 1D71 2AC2 DE D: rcutorture maintainer D: lock annotations, finding and fixing lock bugs -N: Winfried Trümper +N: Winfried Trümper E: [EMAIL PROTECTED] W: http://www.shop.de/~winni/ D: German HOWTO, Crash-Kurs Linux (German, 100 comprehensive pages) D: CD-Writing HOWTO, various mini-HOWTOs D: One-week tutorials on Linux twice a year (free of charge) -D: Linux-Workshop Köln (aka LUG Cologne, Germany), Installfests +D: Linux-Workshop Köln (aka LUG Cologne, Germa
[PATCH] general: convert "kernel" subdirectory to UTF-8
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
Convert the "kernel" subdirectory of the tree to UTF-8. The only file
modified is .
Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
---
I can't get my mail client to send in ISO-8859-1 instead of UTF-8, so the
actual patch is attached in octet-stream format. The below patch is just
for reference and will almost certainly NOT work.
Also, since the patch includes both encodings, whichever encoding you
select while viewing it will display one correct and one garbled line.
However, the bytecodes -are- correct.
diff -uprN linux-2.6.21-rc7.orig/kernel/sys.c linux-2.6.21-rc7.mod/kernel/sys.c
--- linux-2.6.21-rc7.orig/kernel/sys.c 2007-04-17 11:42:13.0 -0400
+++ linux-2.6.21-rc7.mod/kernel/sys.c 2007-04-17 13:16:59.0 -0400
@@ -1292,7 +1292,7 @@ asmlinkage long sys_setfsuid(uid_t uid)
}
/*
- * Samma på svenska..
+ * Samma på svenska..
*/
asmlinkage long sys_setfsgid(gid_t gid)
{
patch-kernel.bin
Description: Binary data
[PATCH] crypto: convert "crypto" subdirectory to UTF-8
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]> Convert the subdirectory "crypto" to UTF-8. The files changed are and . Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]> --- I can't get my mail client to send in ISO-8859-1 instead of UTF-8, so the actual patch is attached in octet-stream format. The below patch is just for reference and will almost certainly NOT work. Also, since the patch includes both encodings, whichever encoding you select while viewing it will display one correct and one garbled line. However, the bytecodes -are- correct. diff -uprN linux-2.6.21-rc7.orig/crypto/api.c linux-2.6.21-rc7.mod/crypto/api.c --- linux-2.6.21-rc7.orig/crypto/api.c 2007-04-17 11:41:50.0 -0400 +++ linux-2.6.21-rc7.mod/crypto/api.c 2007-04-17 13:21:52.0 -0400 @@ -6,7 +6,7 @@ * Copyright (c) 2005 Herbert Xu <[EMAIL PROTECTED]> * * Portions derived from Cryptoapi, by Alexander Kjeldaas <[EMAIL PROTECTED]> - * and Nettle, by Niels Möller. + * and Nettle, by Niels Möller. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the Free diff -uprN linux-2.6.21-rc7.orig/crypto/fcrypt.c linux-2.6.21-rc7.mod/crypto/fcrypt.c --- linux-2.6.21-rc7.orig/crypto/fcrypt.c 2007-04-17 11:41:50.0 -0400 +++ linux-2.6.21-rc7.mod/crypto/fcrypt.c2007-04-17 13:21:52.0 -0400 @@ -10,7 +10,7 @@ * * Based on code: * - * Copyright (c) 1995 - 2000 Kungliga Tekniska Högskolan + * Copyright (c) 1995 - 2000 Kungliga Tekniska Högskolan * (Royal Institute of Technology, Stockholm, Sweden). * All rights reserved. * patch-crypto.bin Description: Binary data
Re: [PATCH] general: convert "kernel" subdirectory to UTF-8
> > I can't get my mail client to send in ISO-8859-1 instead of UTF-8, so the > > Actually your mail is encoded in iso-8859-15. Is it? I've sent a bajillion test messages to myself and they all ended up UTF-8, meaning it actually recursively encoded the original UTF-8 in the message. I'm using alpine. Know any way to explicitly set another encoding such that it does -not- get converted on the other end? I tried the character-set and charset options but they didn't help at 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/
[PATCH] include files: convert "include" subdirectory to UTF-8
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
Convert the "include" subdirectory to UTF-8. The following files are
changed.
include/net/irda/{iriap.h,irttp.h,iriap_event.h,parameters.h}
include/net/irda/{irlmp_frame.h,irlan_eth.h,irlan_provider.h}
include/net/irda/{irlan_event.h,wrapper.h,af_irda.h,irlmp.h}
include/net/irda/{irmod.h,irlap.h,irlan_filter.h,timer.h,irqueue.h}
include/net/irda/{irda.h,irias_object.h,irlan_client.h}
include/net/irda/{irlan_common.h,irlmp_event.h}
include/linux/i2c-algo-pcf.h
include/linux/crypto.h
include/linux/meye.h
include/linux/sonypi.h
include/linux/i2c-algo-bit.h
include/linux/irda.h
include/asm-arm/arch-imx/imx-regs.h
include/asm-arm/arch-omap/{board.h,dma.h,gpio.h}
include/asm-arm/arch-integrator/platform.h
include/asm-m68k/{atariints.h,atarihw.h}
include/asm-ppc/hydra.h
Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
---
I can't get my mail client to send in ISO-8859-1 explicitly instead of
whatever it decides I want, so the actual patch is attached in
octet-stream format. The below patch is just for reference and will very
likely NOT work, unless this time it picks ISO-8859-1.
Also, since the patch includes both encodings, whichever encoding you
select while viewing it will display one correct and one garbled line.
However, the bytecodes -are- correct.
diff -uprN linux-2.6.21-rc7.orig/include/asm-arm/arch-imx/imx-regs.h
linux-2.6.21-rc7.mod/include/asm-arm/arch-imx/imx-regs.h
--- linux-2.6.21-rc7.orig/include/asm-arm/arch-imx/imx-regs.h 2007-02-04
13:44:54.0 -0500
+++ linux-2.6.21-rc7.mod/include/asm-arm/arch-imx/imx-regs.h2007-04-17
13:43:32.0 -0400
@@ -297,7 +297,7 @@
#define SAR(x) __REG2( IMX_DMAC_BASE + 0x80, (x) << 6)/* Source
Address Registers */
#define DAR(x) __REG2( IMX_DMAC_BASE + 0x84, (x) << 6)/* Destination
Address Registers */
#define CNTR(x) __REG2( IMX_DMAC_BASE + 0x88, (x) << 6)/* Count
Registers */
-#define CCR(x) __REG2( IMX_DMAC_BASE + 0x8c, (x) << 6)/* Control
Registers */
+#define CCR(x) __REG2( IMX_DMAC_BASE + 0x8c, (x) << 6)/* Control
Registers */
#define RSSR(x) __REG2( IMX_DMAC_BASE + 0x90, (x) << 6)/* Request
source select Registers */
#define BLR(x) __REG2( IMX_DMAC_BASE + 0x94, (x) << 6)/* Burst length
Registers */
#define RTOR(x) __REG2( IMX_DMAC_BASE + 0x98, (x) << 6)/* Request
timeout Registers */
diff -uprN linux-2.6.21-rc7.orig/include/asm-arm/arch-integrator/platform.h
linux-2.6.21-rc7.mod/include/asm-arm/arch-integrator/platform.h
--- linux-2.6.21-rc7.orig/include/asm-arm/arch-integrator/platform.h
2007-02-04 13:44:54.0 -0500
+++ linux-2.6.21-rc7.mod/include/asm-arm/arch-integrator/platform.h
2007-04-17 13:38:29.0 -0400
@@ -17,7 +17,7 @@
* from .s file by awk -f s2h.awk
*/
/**
- * * Copyright © ARM Limited 1998. All rights reserved.
+ * * Copyright © ARM Limited 1998. All rights reserved.
* ***/
/*
*
diff -uprN linux-2.6.21-rc7.orig/include/asm-arm/arch-omap/board.h
linux-2.6.21-rc7.mod/include/asm-arm/arch-omap/board.h
--- linux-2.6.21-rc7.orig/include/asm-arm/arch-omap/board.h 2007-02-04
13:44:54.0 -0500
+++ linux-2.6.21-rc7.mod/include/asm-arm/arch-omap/board.h 2007-04-17
13:38:29.0 -0400
@@ -4,7 +4,7 @@
* Information structures for board-specific data
*
* Copyright (C) 2004 Nokia Corporation
- * Written by Juha Yrjölä <[EMAIL PROTECTED]>
+ * Written by Juha Yrjölä <[EMAIL PROTECTED]>
*/
#ifndef _OMAP_BOARD_H
diff -uprN linux-2.6.21-rc7.orig/include/asm-arm/arch-omap/dma.h
linux-2.6.21-rc7.mod/include/asm-arm/arch-omap/dma.h
--- linux-2.6.21-rc7.orig/include/asm-arm/arch-omap/dma.h 2007-02-04
13:44:54.0 -0500
+++ linux-2.6.21-rc7.mod/include/asm-arm/arch-omap/dma.h2007-04-17
13:38:29.0 -0400
@@ -2,7 +2,7 @@
* linux/include/asm-arm/arch-omap/dma.h
*
* Copyright (C) 2003 Nokia Corporation
- * Author: Juha Yrjölä <[EMAIL PROTECTED]>
+ * Author: Juha Yrjölä <[EMAIL PROTECTED]>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
diff -uprN linux-2.6.21-rc7.orig/include/asm-arm/arch-omap/gpio.h
linux-2.6.21-rc7.mod/include/asm-arm/arch-omap/gpio.h
--- linux-2.6.21-rc7.orig/include/asm-arm/arch-omap/gpio.h 2007-04-17
11:42:07.0 -0400
+++ linux-2.6.21-rc7.mod/include/asm-arm/arch-omap/gpio.h 2007-04-17
13:38:29.0 -0400
@@ -5,7 +5,7 @@
*
* Copyright (C) 2003-2005 Nokia Corporation
*
- * Written by Juha Yrjölä <[EMAIL P
[PATCH] sound: convert "sound" subdirectory to UTF-8
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
Convert the "sound" subdirectory to UTF-8. The following files are
changed.
sound/oss/{trident.c,es1371.c,pas2_pcm.c}
sound/oss/emu10k1/{passthrough.h,passthrough.c}
sound/pci/mixart/mixart.c
Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
---
I can't get my mail client to send in ISO-8859-1 explicitly instead of
whatever it decides I want, so the actual patch is attached in
octet-stream format. The below patch is just for reference and will very
likely NOT work, unless this time it picks ISO-8859-1.
Also, since the patch includes both encodings, whichever encoding you
select while viewing it will display one correct and one garbled line.
However, the bytecodes -are- correct.
diff -uprN linux-2.6.21-rc7.orig/sound/oss/emu10k1/passthrough.c
linux-2.6.21-rc7.mod/sound/oss/emu10k1/passthrough.c
--- linux-2.6.21-rc7.orig/sound/oss/emu10k1/passthrough.c 2007-02-04
13:44:54.0 -0500
+++ linux-2.6.21-rc7.mod/sound/oss/emu10k1/passthrough.c2007-04-17
13:55:45.0 -0400
@@ -1,13 +1,13 @@
/*
**
* passthrough.c -- Emu10k1 digital passthrough
- * Copyright (C) 2001 Juha Yrjölä <[EMAIL PROTECTED]>
+ * Copyright (C) 2001 Juha Yrjölä <[EMAIL PROTECTED]>
*
**
*
* Date Author Summary of changes
* -- --
- * May 15, 2001Juha Yrjölä base code release
+ * May 15, 2001Juha Yrjölä base code release
*
**
*
diff -uprN linux-2.6.21-rc7.orig/sound/oss/emu10k1/passthrough.h
linux-2.6.21-rc7.mod/sound/oss/emu10k1/passthrough.h
--- linux-2.6.21-rc7.orig/sound/oss/emu10k1/passthrough.h 2007-02-04
13:44:54.0 -0500
+++ linux-2.6.21-rc7.mod/sound/oss/emu10k1/passthrough.h2007-04-17
13:55:45.0 -0400
@@ -1,13 +1,13 @@
/*
**
* passthrough.h -- Emu10k1 digital passthrough header file
- * Copyright (C) 2001 Juha Yrjölä <[EMAIL PROTECTED]>
+ * Copyright (C) 2001 Juha Yrjölä <[EMAIL PROTECTED]>
*
**
*
* Date Author Summary of changes
* -- --
- * May 15, 2001Juha Yrjölä base code release
+ * May 15, 2001Juha Yrjölä base code release
*
**
*
diff -uprN linux-2.6.21-rc7.orig/sound/oss/es1371.c
linux-2.6.21-rc7.mod/sound/oss/es1371.c
--- linux-2.6.21-rc7.orig/sound/oss/es1371.c2007-04-17 11:42:18.0
-0400
+++ linux-2.6.21-rc7.mod/sound/oss/es1371.c 2007-04-17 13:55:45.0
-0400
@@ -100,7 +100,7 @@
* Tjeerd Mulder <[EMAIL PROTECTED]>
*05.01.2001 0.29 Hopefully updates will not be required anymore when
Creative bumps
* the CT5880 revision.
- * suggested by Stephan Müller <[EMAIL PROTECTED]>
+ * suggested by Stephan Müller <[EMAIL PROTECTED]>
*31.01.2001 0.30 Register/Unregister gameport
* Fix SETTRIGGER non OSS API conformity
*14.07.2001 0.31 Add list of laptops needing amplifier control
diff -uprN linux-2.6.21-rc7.orig/sound/oss/pas2_pcm.c
linux-2.6.21-rc7.mod/sound/oss/pas2_pcm.c
--- linux-2.6.21-rc7.orig/sound/oss/pas2_pcm.c 2007-02-04 13:44:54.0
-0500
+++ linux-2.6.21-rc7.mod/sound/oss/pas2_pcm.c 2007-04-17 13:55:45.0
-0400
@@ -85,7 +85,7 @@ static int pcm_set_speed(int arg)
* come from the SDK found on ftp.uwp.edu:/pub/msdos/proaudio/.
*
* I cleared bit 5 of these values, since that bit controls the master
-* mute flag. (Olav Wölfelschneider)
+* mute flag. (Olav Wölfelschneider)
*
*/
#if !defined NO_AUTO_FILTER_SET
diff -uprN linux-2.6.21-rc7.orig/sound/oss/trident.c
linux-2.6.21-rc7.mod/sound/oss/trident.c
--- linux-2.6.21-rc7.orig/sound/oss/trident.c 2007-04-17 11:42:18.0
-0400
+++ linux-2.6.21-rc7.mod/sound/oss/trident.c2007-04-17 13:55:45.0
-0400
@@ -18,7 +18,7 @@
* Ollie Lho <[EMAIL PROTECTED]> SiS 7018 Audio Core Support
* Ching-Ling Lee <[EMAIL PROTECTED]> ALi 5451 Audio Core Support
* Matt Wu <[EMAIL PROTECTED]> ALi 5451 Audio Core Support
- * Peter Wächtler <[EMAIL PROTECTED]> CyberPro5050 support
+ * Peter Wächtler <[EMAIL PROTECTED]> CyberPro5050 support
* Muli Ben-Yehuda <[EMAIL PROTECT
UTF-8 Patches
Alright, was anybody able to apply these? The major portion of the changes still remains and I want to make sure what I'm doing is working before I spend a lot of time on it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cciss: Fix warnings during compilation under 32bitenvironment
On Fri, 20 Apr 2007, Andrew Morton wrote: > On Fri, 20 Apr 2007 16:20:59 -0400 > James Bottomley <[EMAIL PROTECTED]> wrote: > > > On Fri, 2007-04-20 at 12:30 -0700, Andrew Morton wrote: > > > On Fri, 20 Apr 2007 14:50:06 -0400 > > > James Bottomley <[EMAIL PROTECTED]> wrote: > > > > > > > > CONFIG_LBD=y gives us an additional 3kb of instructions on i386 > > > > > allnoconfig. Other architectures might do less well. It's not a huge > > > > > difference, but that's the way in which creeping bloatiness happens. > > > > > > > > OK, sure, but if we really care about this saving, then unconditionally > > > > casting to u64 is therefore wrong as well ... this is starting to open > > > > quite a large can of worms ... > > > > > > > > For the record, if we have to do this, I fancy sector_upper_32() ... we > > > > should already have some similar accessor for dma_addr_t as well. > > > > > > hm. How about this? > > > > > > --- a/include/linux/kernel.h~upper-32-bits > > > +++ a/include/linux/kernel.h > > > @@ -40,6 +40,17 @@ extern const char linux_proc_banner[]; > > > #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d)) > > > #define roundup(x, y) x) + ((y) - 1)) / (y)) * (y)) > > > > > > +/** > > > + * upper_32_bits - return bits 32-63 of a number > > > + * @n: the number we're accessing > > > + * > > > + * A basic shift-right of a 64- or 32-bit quantity. Use this to suppress > > > + * the "right shift count >= width of type" warning when that quantity is > > > + * 32-bits. > > > + */ > > > +#define upper_32_bits(n) (((u64)(n)) >> 32) > > > > Won't this have the unwanted side effect of promoting everything in a > > calculation to long long on 32 bit platforms, even if n was only 32 > > bits? > > bummer. > > > > + > > > + > > > #define KERN_EMERG "<0>" /* system is unusable > > > */ > > > #define KERN_ALERT "<1>" /* action must be taken immediately > > > */ > > > #define KERN_CRIT "<2>" /* critical conditions > > > */ > > > _ > > > > > > It seems to generate the desired code. I avoided Alan's ((n >> 31) >> 1) > > > trick because it'll generate peculiar results with signed 64-bit > > > quantities. > > > > I've seen the trick done similarly with ((n >> 16) >> 16) which > > shouldn't have the issue. > > That works if we know the caller is treating the return value as 32 bits, > but we don't know that. > > If we have > > #define upper_32_bits(x) ((x >> 16) >> 16) > > then > > upper_32_bits(0x) > > will return 0x if it's treated as 32-bits, but it'll return > 0x if the caller is using 64-bits. > > I spose > > #define upper_32_bits(x) ((u32)((x >> 16) >> 16)) > > will do the trick. What about this? #define upper_32_bits(x) (sizeof(x) == 8 ? (u64)(x) >> 32 : 0) The u64 cast prevents the sign bit from being carried over and therefore eliminates the need for a subsequent cast to u32 since the upper 32 of the result will be 0. Shouldn't be any case where an integer gets promoted if 64 bits is the largest possible promotion. Assuming, of course, I'm not an idiot. Which I somewhat frequently am. - 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] utilities: add helper functions for safe 64-bit integer operations as 32-bit halves
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]> Add helper functions "upper_32_bits" and "lower_32_bits" to to allow 64-bit integers to be separated into their 32-bit upper and lower halves without promoting integers, without stretching sign bits, and without generating compiler warnings when used with any integer not greater than 64 bits wide. High-order bits are assumed to be zero for integers with fewer than 64 of them. Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]> --- Using these functions with signed quantities is an error, especially if you read a 32-bit quantity from disk that happens to have the high bit set into an int on a 32-bit machine, then use it with a function taking a u64 which screws your data. When switching to using these functions, it's a good opportunity to check for these signedness errors. (Haven't we learned anything over the past decades of computing about assuming that one little bit doesn't matter?) Not sure exactly whom the maintainer is for this, so I added [EMAIL PROTECTED] It's certainly not limited to one subsystem anymore, and converting the whole kernel to this could be a good step for readability and correctness across architectures of any word size. --- linux-2.6.21-rc7-git4.orig/include/linux/kernel.h 2007-04-20 20:22:13.0 -0400 +++ linux-2.6.21-rc7-git4.mod/include/linux/kernel.h2007-04-20 20:37:41.0 -0400 @@ -40,6 +40,23 @@ extern const char linux_proc_banner[]; #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d)) #define roundup(x, y) x) + ((y) - 1)) / (y)) * (y)) +/** + * lower_32_bits, upper_32_bits - separate the halves of a 64-bit integer + * @n: the integer to separate + * + * Separate a 64-bit integer into its upper and lower 32-bit halves. + * Designed to avoid integer promotions and compiler warnings when used + * with smaller integers, in which case the missing bits are assumed to + * be zero. Designed to treat integers as unsigned whether or not they + * really are. (If you are using these with signed integers, your code + * is almost certainly wrong. The cast is good for people too lazy to + * type "unsigned" in their code, since breaking things is bad.) + * + * These assume the integer used is NOT greater than 64 bits wide. + */ +#define upper_32_bits(n) (sizeof(n) == 8 ? (u64)(n) >> 32 : 0) +#define lower_32_bits(n) (sizeof(n) == 8 ? (u32)(n) : (n)) + #defineKERN_EMERG "<0>" /* system is unusable */ #defineKERN_ALERT "<1>" /* action must be taken immediately */ #defineKERN_CRIT "<2>" /* critical conditions */ - 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] utilities: add helper functions for safe 64-bit integer operations as 32-bit halves
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]> Add helper functions "upper_32_bits" and "lower_32_bits" to to allow 64-bit integers to be separated into their 32-bit upper and lower halves without promoting integers, without stretching sign bits, and without generating compiler warnings when used with any integer not greater than 64 bits wide. High-order bits are assumed to be zero for integers with fewer than 64 of them. Result values are always 32-bit unsigned. Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]> --- > > +#define upper_32_bits(n) (sizeof(n) == 8 ? (u64)(n) >> 32 : 0) > > It's very unclear what type this returns, in terms of both size and > signedness. Perhaps it always returns a u64, dunno. If it does, that will > cause the arithmetic which uses this macro to go 64-bit too. Casting the > whole return value to u32 would fix all those doubts up. If the argument is 64-bit, the return value is 64-bit; otherwise, the return value is the same as the size of the argument. This prevents integer promotion. I was trying to also not promote,, say, a short int, if for some stupid reason somebody was using one. But you're right, a cast is clearer, and the functions are clearly intended for 32-bit arithmetic. > > +#define lower_32_bits(n) (sizeof(n) == 8 ? (u32)(n) : (n)) > > n&0x would be simpler. I suppose. I'm trying to be careful and account for stupid edge cases, but then again, such code is horribly broken so we can instead ignore them? We shall assume the mask gets promoted as necessary. > Do we actually have any call for this? It enhances readability and prevents compiler warnings without increasing code-local complexity. Besides, if we have upper_32_bits, we should have lower_32_bits. Two similarly-named function calls is better than a function call and a mask. And it's really nice to be able to write code that is word-size independent and also not cluttered. And if any code declares macros like this now, they can be eliminated and make a little more utility code central. --- linux-2.6.21-rc7-git4.orig/include/linux/kernel.h 2007-04-20 20:22:13.0 -0400 +++ linux-2.6.21-rc7-git4.mod/include/linux/kernel.h2007-04-21 08:59:01.0 -0400 @@ -40,6 +40,24 @@ extern const char linux_proc_banner[]; #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d)) #define roundup(x, y) x) + ((y) - 1)) / (y)) * (y)) +/** + * lower_32_bits, upper_32_bits - separate the halves of a 64-bit integer + * @n: the integer to separate + * + * Separate a 64-bit integer into its upper and lower 32-bit halves. + * Designed to avoid integer promotions and compiler warnings when used + * with smaller integers, in which case the missing bits are assumed to + * be zero. Designed to treat integers as unsigned whether or not they + * really are. (If you are using these with signed integers, your code + * is almost certainly wrong. The cast is good for people too lazy to + * type "unsigned" in their code, since breaking things is bad.) + * + * These assume the integer used is NOT greater than 64 bits wide. + * Return values are always 32-bit unsigned integers. + */ +#define upper_32_bits(n) ((u32)(sizeof(n) == 8 ? (u64)(n) >> 32 : 0)) +#define lower_32_bits(n) ((u32)(n & ~(u32)0)) + #defineKERN_EMERG "<0>" /* system is unusable */ #defineKERN_ALERT "<1>" /* action must be taken immediately */ #defineKERN_CRIT "<2>" /* critical conditions */ - 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: VMware, x86_64 and 2.6.21.
> > > if you want to ask questions about proprietary kernel stuff you're > > > better off asking the vendor directly, not lkml > > > > I did, but given that it the failure only appeared with a change of > > vanilla kernel version, I didn't think it was out of place to ask here > > too. > > No, it's still totally offtopic here. And a change of vanilla kernel version leading to breakage is not a sufficient condition to conclude the kernel's at fault. The entire history of computing is saturated with examples of coders doing stupid things with foolish assumptions and incidental interfaces of operating systems (early games on *-DOS being a prime example) that are subsequently broken by new versions of the operating system. That's programs being stupid, not the operating system. - 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: gmail is a bit too popular..
> In the linux-kernel -list subscribers domain popularity > analysis I got following results: > >2101 gmail.com > 49 googlemail.com > 46 gmx.de > 41 redhat.com > 33 yahoo.com > 23 suse.de > 22 gmx.net > 21 comcast.net > > > The gmail is so popular, that with their somewhat rudimentary > inbound MTA software this kind of recipient masses take horrible > time to feed in... Mere 0.5-0.7 seconds per recipient, but.. > > So far we have tried to feed all recipients in one go per > message - that is sending 2100 RCPT TO -lines in one swoop, > and the system has taken some 15-25 minutes per message to > feed it to gmail. We are running the delivery 20 streams in > parallel, so it isn't quite as bad as it sounds.. > > I do have one thing that gmail could enable to speed up the message > delivery (a lot!) from VGER and other list delivery sources. > That single magic needed thing is called "PIPELINING" support > at gmail's inbound MX servers. With suitably well behaving > smtpserver it is really trivial to implement, all real difficult > magic is at the sending side smtp client codes. > > Once upon a time I implemented that thing for a trans-atlantic > SMTP fanout feed -- message delivery time became slashed from > hundreds of RTT delays to mere few.. How about some elitism here? Dedicate a certain number of streams to everything-except-gmail, so MTAs from the 21st century can get their mail faster, and set the rest on gmail-only. Slows down gmail and speeds up the rest? - 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] fs/buffer.c: Loop rewrite within grow_buffers for finding sizebits
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
This patch alters the (do...while) construct to a simple (while) and saves
one increment operation. It's entirely possible that gcc optimizes away
the first iteration anyway, but in case it doesn't (and also because it's
easier to read this way), I think this is better.
Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
---
--- linux-2.6.20.4/fs/buffer.c.orig 2007-03-26 09:42:15.0 -0400
+++ linux-2.6.20.4/fs/buffer.c 2007-03-26 10:10:25.0 -0400
@@ -1045,10 +1045,10 @@ grow_buffers(struct block_device *bdev,
pgoff_t index;
int sizebits;
- sizebits = -1;
- do {
+ sizebits = 0;
+ while ((size << sizebits) < PAGE_SIZE) {
sizebits++;
- } while ((size << sizebits) < PAGE_SIZE);
+ }
index = block >> sizebits;
-
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] block layer: Add bdev capacity helper function get_sect_count
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
Add static inline function get_sect_count to include/linux/genhd.h to
complement get_start_sect. Returns sector_t capacity of block device
whether it is whole or a partition.
Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
---
This will be useful for fill_super functions of filesystems with online
resizing for checks against recorded and actual device size.
get_start_sect and get_sect_count are helper functions useful to keep
things from breaking in case the block_device structure decides to change.
Applied against Linux v2.6.20.6.
--- linux-2.6.20.6-orig/include/linux/genhd.h 2007-04-06 16:02:48.0
-0400
+++ linux-2.6.20.6-mod/include/linux/genhd.h2007-04-07 11:58:55.0
-0400
@@ -244,6 +244,10 @@ static inline sector_t get_start_sect(st
{
return bdev->bd_contains == bdev ? 0 : bdev->bd_part->start_sect;
}
+static inline sector_t get_sect_count(struct block_device *bdev)
+{
+ return bdev->bd_contains == bdev ? bdev->bd_disk->capacity :
bdev->bd_part->nr_sects;
+}
static inline sector_t get_capacity(struct gendisk *disk)
{
return disk->capacity;
-
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] partitions: Enhance Kconfig help text for EESOX and MSDOS formats
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]> Adds help text for ACORN_PARTITION_EESOX and improves help text for MSDOS_PARTITION in fs/partitions/Kconfig. Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]> --- Applied against Linux v2.6.20.6. --- linux-2.6.20.6-orig/fs/partitions/Kconfig 2007-04-06 16:02:48.0 -0400 +++ linux-2.6.20.6-mod/fs/partitions/Kconfig2007-04-07 13:22:17.0 -0400 @@ -32,6 +32,10 @@ config ACORN_PARTITION_EESOX bool "EESOX partition support" if PARTITION_ADVANCED default y if ARCH_ACORN depends on ACORN_PARTITION + help + EESOX SCSI card on-disk partition format support for Acorn + systems. If you have one of these cards, or want to use a disk + written by one, say Y. config ACORN_PARTITION_ICS bool "ICS partition support" if PARTITION_ADVANCED @@ -108,7 +112,11 @@ config MSDOS_PARTITION bool "PC BIOS (MSDOS partition tables) support" if PARTITION_ADVANCED default y help - Say Y here. + Standard PC-compatible partition table support for Linux. Used by + i386 systems, Linux/Windows dual-boot systems, and many others. + Unless you are certain your system does not use this partition + table format, and you're not using any disks from a system that + does, say Y. config BSD_DISKLABEL bool "BSD disklabel (FreeBSD partition tables) support" - 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/
[RFC] partitions: CONFIG_BLK_DEV_MD and modular RAID support
(Linux v2.6.20.6.) The function md_autodetect_dev is defined in drivers/md/md.c. Its declaration is on line 1443, outside of conditionals. However, both its use on line 1455 and its definition on line 5600 are inside "#ifndef MODULE" conditionals. So it seems obvious that the declaration should be inside conditionals as well. However, this function is separately declared and used in fs/partitions/check.c but not inside the same conditional, which means if md.c is compiled as a module, check.c will be referencing an undefined symbol. Should the conditionals around md_autodetect_dev be changed to make sure CONFIG_BLK_DEV_MD=y, or does the function need to be extracted from md.c so it can be used by check.c in any 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/
[PATCH 0/5] partitions: Changes to fs/partitions for readability and efficiency
In addition to the Kconfig help text patch I submitted earlier, this is a set of patches to touch up the partition handling files and also to change the "array of function pointers" algorithm of the main checking function to "list of calls to possible stub functions" to better fit in with the rest of the kernel code, to reduce memory usage by a few dozen bytes, and to generally be easier (in my opinion) to understand. - 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 1/5] partitions: Touch up comments for check.h and ibm.h
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
Adds top-of-file identifying comments to check.h and ibm.h in
fs/partitions similar to the other files in the directory. Removes an
obsolescent comment from check.h leftover from devfs.
Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
---
add_gd_partition used to be in check.c for devfs. That identifier no
longer exists anywhere within the tree.
--- linux-2.6.20.6-orig/fs/partitions/check.h 2007-04-06 16:02:48.0
-0400
+++ linux-2.6.20.6-mod/fs/partitions/check.h2007-04-07 21:26:10.0
-0400
@@ -1,10 +1,10 @@
+/*
+ * fs/partitions/check.h
+ */
+
#include
#include
-/*
- * add_gd_partition adds a partitions details to the devices partition
- * description.
- */
enum { MAX_PART = 256 };
struct parsed_partitions {
--- linux-2.6.20.6-orig/fs/partitions/ibm.h 2007-04-06 16:02:48.0
-0400
+++ linux-2.6.20.6-mod/fs/partitions/ibm.h 2007-04-07 22:02:18.0
-0400
@@ -1 +1,5 @@
+/*
+ * fs/partitions/ibm.h
+ */
+
int ibm_partition(struct parsed_partitions *, struct block_device *);
-
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 2/5] partitions: Add Kconfig dependency to clear benign compiler warning
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]> Adds a dependency to ACORN_PARTITION_RISCIX in fs/partitions/Kconfig to prevent compilation of the function riscix_partition which is used only within ACORN_PARTITION_CUMANA and ACORN_PARTITION_ADFS sections, thereby preventing an unused-function compiler warning if ACORN_PARTITION_RISCIX is defined and neither of the other two are. Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]> --- Nothing depending on RISCIX is defined except inside CUMANA and ADFS, so without either of those, nothing using the RISCIX stuff is compiled, hance the unused-function warning. --- linux-2.6.20.6-orig/fs/partitions/Kconfig 2007-04-06 16:02:48.0 -0400 +++ linux-2.6.20.6-mod/fs/partitions/Kconfig2007-04-07 22:10:15.0 -0400 @@ -62,7 +62,7 @@ config ACORN_PARTITION_POWERTEC config ACORN_PARTITION_RISCIX bool "RISCiX partition support" if PARTITION_ADVANCED default y if ARCH_ACORN - depends on ACORN_PARTITION + depends on ACORN_PARTITION && (ACORN_PARTITION_CUMANA || ACORN_PARTITION_ADFS) help Once upon a time, there was a native Unix port for the Acorn series of machines called RISCiX. If you say 'Y' here, Linux will be able - 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 3/5] partitions: Add conditionals to acorn.c to clear benign compiler warnings
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
Adds conditional-compilation directives to fs/partitions/acorn.c to
prevent compilation of the functions adfs_partition and linux_partition
which are used only within ACORN_PARTITION_CUMANA and ACORN_PARTITION_ADFS
sections, thereby preventing unused-function compiler warnings if
ACORN_PARTITION is defined and neither of the other two are.
Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
---
Nothing using these two functions is defined except inside CUMANA and
ADFS, so without either of those, nothing using these functions is
compiled, hence the unused-function warning. Both CUMANA and ADFS code use
both functions so they must be included if either symbol is defined.
--- linux-2.6.20.6-orig/fs/partitions/acorn.c 2007-04-06 16:02:48.0
-0400
+++ linux-2.6.20.6-mod/fs/partitions/acorn.c2007-04-07 21:40:39.0
-0400
@@ -25,6 +25,8 @@
#define PARTITION_RISCIX_SCSI 2
#define PARTITION_LINUX9
+#if defined(CONFIG_ACORN_PARTITION_CUMANA) ||
defined(CONFIG_ACORN_PARTITION_ADFS)
+
static struct adfs_discrecord *
adfs_partition(struct parsed_partitions *state, char *name, char *data,
unsigned long first_sector, int slot)
@@ -49,6 +51,8 @@ adfs_partition(struct parsed_partitions
return dr;
}
+#endif
+
#ifdef CONFIG_ACORN_PARTITION_RISCIX
struct riscix_part {
@@ -106,6 +110,8 @@ riscix_partition(struct parsed_partition
}
#endif
+#if defined(CONFIG_ACORN_PARTITION_CUMANA) ||
defined(CONFIG_ACORN_PARTITION_ADFS)
+
#define LINUX_NATIVE_MAGIC 0xdeafa1de
#define LINUX_SWAP_MAGIC 0xdeafab1e
@@ -147,6 +153,8 @@ linux_partition(struct parsed_partitions
return slot;
}
+#endif
+
#ifdef CONFIG_ACORN_PARTITION_CUMANA
int
adfspart_check_CUMANA(struct parsed_partitions *state, struct block_device
*bdev)
-
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 4/5] partitions: Add conditionals and static inline stubs to helpers in headers
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
Functions of the form adfspart_check_FOO and foo_partition defined in
fs/partitions/*.h are helper functions called in a deliberate order by
check_partition in check.c. Add conditional-compilation directives and
static inline no-op functions to allow code to indiscriminately call these
functions irrespective of whether they do anything, removing the necessity
of oodles of #ifdef/#endif in function bodies.
Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
---
The next patch changes the check.c code to use these function definitions
in a nicer way.
--- linux-2.6.20.6-orig/fs/partitions/acorn.h 2007-04-06 16:02:48.0
-0400
+++ linux-2.6.20.6-mod/fs/partitions/acorn.h2007-04-07 20:02:51.0
-0400
@@ -7,8 +7,47 @@
* format, and everyone stick to it?
*/
-int adfspart_check_CUMANA(struct parsed_partitions *state, struct block_device
*bdev);
-int adfspart_check_ADFS(struct parsed_partitions *state, struct block_device
*bdev);
-int adfspart_check_ICS(struct parsed_partitions *state, struct block_device
*bdev);
-int adfspart_check_POWERTEC(struct parsed_partitions *state, struct
block_device *bdev);
-int adfspart_check_EESOX(struct parsed_partitions *state, struct block_device
*bdev);
+#ifdef CONFIG_ACORN_PARTITION_ICS
+ int adfspart_check_ICS(struct parsed_partitions *state, struct
block_device *bdev);
+#else
+ static inline int adfspart_check_ICS(struct parsed_partitions *state,
struct block_device *bdev)
+ {
+ return 0;
+ }
+#endif
+
+#ifdef CONFIG_ACORN_PARTITION_POWERTEC
+ int adfspart_check_POWERTEC(struct parsed_partitions *state, struct
block_device *bdev);
+#else
+ static inline int adfspart_check_POWERTEC(struct parsed_partitions
*state, struct block_device *bdev)
+ {
+ return 0;
+ }
+#endif
+
+#ifdef CONFIG_ACORN_PARTITION_EESOX
+ int adfspart_check_EESOX(struct parsed_partitions *state, struct
block_device *bdev);
+#else
+ static inline int adfspart_check_EESOX(struct parsed_partitions *state,
struct block_device *bdev)
+ {
+ return 0;
+ }
+#endif
+
+#ifdef CONFIG_ACORN_PARTITION_CUMANA
+ int adfspart_check_CUMANA(struct parsed_partitions *state, struct
block_device *bdev);
+#else
+ static inline int adfspart_check_CUMANA(struct parsed_partitions
*state, struct block_device *bdev)
+ {
+ return 0;
+ }
+#endif
+
+#ifdef CONFIG_ACORN_PARTITION_ADFS
+ int adfspart_check_ADFS(struct parsed_partitions *state, struct
block_device *bdev);
+#else
+ static inline int adfspart_check_ADFS(struct parsed_partitions *state,
struct block_device *bdev)
+ {
+ return 0;
+ }
+#endif
--- linux-2.6.20.6-orig/fs/partitions/amiga.h 2007-04-06 16:02:48.0
-0400
+++ linux-2.6.20.6-mod/fs/partitions/amiga.h2007-04-07 20:04:10.0
-0400
@@ -2,5 +2,11 @@
* fs/partitions/amiga.h
*/
-int amiga_partition(struct parsed_partitions *state, struct block_device
*bdev);
-
+#ifdef CONFIG_AMIGA_PARTITION
+ int amiga_partition(struct parsed_partitions *state, struct
block_device *bdev);
+#else
+ static inline int amiga_partition(struct parsed_partitions *state,
struct block_device *bdev)
+ {
+ return 0;
+ }
+#endif
--- linux-2.6.20.6-orig/fs/partitions/atari.h 2007-04-06 16:02:48.0
-0400
+++ linux-2.6.20.6-mod/fs/partitions/atari.h2007-04-07 20:05:34.0
-0400
@@ -31,4 +31,11 @@ struct rootsector
u16 checksum;/* checksum for bootable disks */
} __attribute__((__packed__));
-int atari_partition(struct parsed_partitions *state, struct block_device
*bdev);
+#ifdef CONFIG_ATARI_PARTITION
+ int atari_partition(struct parsed_partitions *state, struct
block_device *bdev);
+#else
+ static inline int atari_partition(struct parsed_partitions *state,
struct block_device *bdev)
+ {
+ return 0;
+ }
+#endif
--- linux-2.6.20.6-orig/fs/partitions/efi.h 2007-04-06 16:02:48.0
-0400
+++ linux-2.6.20.6-mod/fs/partitions/efi.h 2007-04-07 20:06:28.0
-0400
@@ -106,7 +106,14 @@ typedef struct _legacy_mbr {
} __attribute__ ((packed)) legacy_mbr;
/* Functions */
-extern int efi_partition(struct parsed_partitions *state, struct block_device
*bdev);
+#ifdef CONFIG_EFI_PARTITION
+ int efi_partition(struct parsed_partitions *state, struct block_device
*bdev);
+#else
+ static inline int efi_partition(struct parsed_partitions *state, struct
block_device *bdev)
+ {
+ return 0;
+ }
+#endif
#endif
--- linux-2.6.20.6-orig/fs/partitions/ibm.h 2007-04-06 16:02:48.0
-0400
+++ linux-2.6.20.6-mod/fs/partitions/ibm.h 2007-04-07 22:06:16.0
-0400
@@ -1 +1,8 @@
-int ibm_partition(struct parsed_partitions *, struct
[PATCH 5/5] partitions: Rewrite check_partition to remove necessity of check_part
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
Removes the entire check_part array and uses the presence of new stub
functions in header files in fs/partitions to call them directly in a list
and let the compiler optimize away any that aren't compiled in. Also fixes
a bug where " unable to read partition table" would never be printed.
Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
---
I did this because it seems to be much easier to understand. And even
though the memory used by the array was only sizeof(void*)*n+1 for the
number of partitions configured to be included, that's still unnecessary
usage.
This code also has two warn_unused_result problems, but I don't feel up to
the task of fixing those yet.
Within the old loop, if res < 0, res = 0, and immediately after the loop,
the function returns if res > 0. Therefore, it must be that res == 0 after
the loop. if (!err) is true only if err == 0 so again, res == 0, so if
(!res) is true, and the else condition can never be reached. I
re-interpreted the intent to be "log a message if the partition format is
unrecognized, and log a message if the partition cannot be read but only
if the warning is requested". Judging by the "This is ugly" comment, the
warning is not intended to account for actual I/O errors when reading the
partition-table block, but rather to detect when the partitions are
checked for a device with a medium that has been removed.
--- linux-2.6.20.6-orig/fs/partitions/check.c 2007-04-06 16:02:48.0
-0400
+++ linux-2.6.20.6-mod/fs/partitions/check.c2007-04-07 21:50:22.0
-0400
@@ -41,73 +41,6 @@ extern void md_autodetect_dev(dev_t dev)
int warn_no_part = 1; /*This is ugly: should make genhd removable media aware*/
-static int (*check_part[])(struct parsed_partitions *, struct block_device *)
= {
- /*
-* Probe partition formats with tables at disk address 0
-* that also have an ADFS boot block at 0xdc0.
-*/
-#ifdef CONFIG_ACORN_PARTITION_ICS
- adfspart_check_ICS,
-#endif
-#ifdef CONFIG_ACORN_PARTITION_POWERTEC
- adfspart_check_POWERTEC,
-#endif
-#ifdef CONFIG_ACORN_PARTITION_EESOX
- adfspart_check_EESOX,
-#endif
-
- /*
-* Now move on to formats that only have partition info at
-* disk address 0xdc0. Since these may also have stale
-* PC/BIOS partition tables, they need to come before
-* the msdos entry.
-*/
-#ifdef CONFIG_ACORN_PARTITION_CUMANA
- adfspart_check_CUMANA,
-#endif
-#ifdef CONFIG_ACORN_PARTITION_ADFS
- adfspart_check_ADFS,
-#endif
-
-#ifdef CONFIG_EFI_PARTITION
- efi_partition, /* this must come before msdos */
-#endif
-#ifdef CONFIG_SGI_PARTITION
- sgi_partition,
-#endif
-#ifdef CONFIG_LDM_PARTITION
- ldm_partition, /* this must come before msdos */
-#endif
-#ifdef CONFIG_MSDOS_PARTITION
- msdos_partition,
-#endif
-#ifdef CONFIG_OSF_PARTITION
- osf_partition,
-#endif
-#ifdef CONFIG_SUN_PARTITION
- sun_partition,
-#endif
-#ifdef CONFIG_AMIGA_PARTITION
- amiga_partition,
-#endif
-#ifdef CONFIG_ATARI_PARTITION
- atari_partition,
-#endif
-#ifdef CONFIG_MAC_PARTITION
- mac_partition,
-#endif
-#ifdef CONFIG_ULTRIX_PARTITION
- ultrix_partition,
-#endif
-#ifdef CONFIG_IBM_PARTITION
- ibm_partition,
-#endif
-#ifdef CONFIG_KARMA_PARTITION
- karma_partition,
-#endif
- NULL
-};
-
/*
* disk_name() is used by partition check code and the genhd driver.
* It formats the devicename of the indicated disk into
@@ -149,11 +82,125 @@ const char *__bdevname(dev_t dev, char *
EXPORT_SYMBOL(__bdevname);
+static int
+check_succeeded(int res, struct parsed_partitions *state, int *err)
+{
+ if (res < 0) {
+ /* We have hit an I/O error which we don't report now.
+* But record it, and let the others do their job.
+*/
+ *err = res;
+ res = 0;
+ }
+
+ if (!res) {
+ memset(state->parts, 0, sizeof(state->parts));
+ }
+
+ return res;
+}
+
+static struct parsed_partitions *
+do_check_list(struct parsed_partitions *state, struct block_device *bdev)
+{
+ int err;
+
+ err = 0;
+
+/*
+* Probe partition formats with tables at disk address 0
+* that also have an ADFS boot block at 0xdc0.
+*/
+ if (check_succeeded(adfspart_check_ICS(state, bdev), state, &err)) {
+ return state;
+ }
+ if (check_succeeded(adfspart_check_POWERTEC(state, bdev), state, &err))
{
+ return state;
+ }
+ if (check_succeeded(adfspart_check_EESOX(state, bdev), state, &err)) {
+ return state;
+ }
+
+/*
+* Now move on to formats that only have partition info at
+* disk address 0xdc0
Re: I give up
> >So fix tar to not do silly things. > >Kernel major:minor numbers are not stable. > > YOU Tell the tar people, they are flabbergasted that linux is apparently > the only unstable OS that tar can be run on. Linux is not unstable. It's developmental! Linux is like one giant international research project marching toward the future of computing. MacOS (oh, how I miss System 7.5.5), Windows (shoot me, please), BSD (wannabe GNU/Linux), and everything else are there just for companies to spend money on and idiots to drool over until Linux is ready to stand up and say "Yo. It's just bugfixes and improvements from here. You can put the Legos down now." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: I give up
> > I violently agree on that point, but the limited conversations I've had with > > the tar maintainer so far indicates that AFAHIC, its linux that's broken. A > > new device number is a new disk and must be treated as such. > > Sumbit a patch adding an option to ignore the device number, and slap him > around a bit with a large trout ;) I think that's especially true. If a user begins with a single full disk for their entire filesystem, uses tar to backup, and then later adds a second disk, copies everything from /usr and /home onto partitions there (making sure to preserve all interesting bits like ctime/mtime), and mounts them over the original directories, tar should not decide that every file in /usr and /home was deleted and recreated. - 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: Kernel traces coming back with trash/clutter
> I am experimenting with the kernel (CentOSv4.4 x86_64, 2.6.9-42.0.10) > and I have added a number of traces in some relatively sensitive code > in the page cache and some i/o functions. > > I am getting this odd content in the trace log (dmesg), and I cannot > figure out what it is or why it is there. > > 4296757675 pdflush(80): do_writepages: map>ops>wrtpgs a0195ff5 > 4296757675 pdflush(80): mpage_writepages w/b index 49728 pages 256000 > <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7> > <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7> > <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7> > <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7> > <7><7><7><7><7>__bio_add_page: 2x ph 88>=128 || hw 88>=88 || 360448>max > 802525d8 generic_make_request(bio 01017c745300) 50729472, 704 > __make_request(q 0101b9293870, bio 01017c745300: sdc; 50729600, 704) > ll_new_hw_segment: 70 + 29 > 88 > <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7> > <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7> > <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7> > <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7> > <7><7><7><7>__bio_add_page: 2x ph 88>=128 || hw 88>=88 || 360448>max > 802525d8 generic_make_request(bio 01017c745a80) 50730176, 704 > __make_request(q 0101b9293870, bio 01017c745a80: sdc; 50730304, 704) > 4296757684 swapper(0): dl_mv2dsp: sdc start 50710368 secs 1408 > > (The lines with the <7>s in them are long - I wrapped them for ease of > reading and to keep the width down somewhat.) > > Any feedback that might illuminate this would be welcome. Please CC > me personally as I am not yet able to subscribe to this list > (apologies). "<7>" is KERN_DEBUG in , used with printk. Are you using printk in the following forms? printk(KERN_DEBUG "A debug message.\n"); ...or... const char msg_debug[] = KERN_DEBUG "A debug message.\n"; printk(msg_debug); Perhaps you have something looping that's outputting KERN_DEBUG with a null message? Or one of your diagnostic printk statements includes KERN_DEBUG with no actual message? Remember, if you have a string in a variable without a KERN_* prependation, you can do this. printk(KERN_DEBUG "%s\n", debug_message); - 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: Kernel traces coming back with trash/clutter
> > > I am getting this odd content in the trace log (dmesg), and I cannot > > > figure out what it is or why it is there. > > > > > > <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7> > > > <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7> > > > <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7> > > > <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7> > > > <7><7><7><7><7>__bio_add_page: 2x ph 88>=128 || hw 88>=88 || 360448>max > > > 802525d8 generic_make_request(bio 01017c745300) 50729472, 704 > > > > Perhaps you have something looping that's outputting KERN_DEBUG with a > > null message? Or one of your diagnostic printk statements includes > > KERN_DEBUG with no actual message? > > > No, they are all KERN_DEBUG"some string here", almost all with > some formatted output as well. Could I be overloading the printk > output buffer, as in possibly too tightly repeated/looped code to be > able to output it all? It is possible, I suppose. Is what you're working on open-source? If so, you could send it to me and I could try and reproduce it here and track it down. If you want me to, that is. (If you do send, please include a ".config".) Otherwise, I couldn't tell you what it might be. Make sure all your messages end with '\n', make sure you're not accidentally using the wrong formatting codes and it's backing over previous output with ^H or something. You could confirm or rule out the possibility of overflowing the printk buffers by writing a dummy module with a tight loop of nothing but printk statements with counters to see if you can get it to asplode. - 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: Reasons to merge suspend2.
> I didn't read your whole post, it's way too long, but I would like to see > your patch in mainline as an option to swsusp. What would make this > infeasible? For one thing, Linus said not but yesterday that he doesn't want multiple competing suspend algorithms like this in the kernel at once. (If I parsed his message correctly, he doesn't want any in the kernel, but he's putting up with it because it seems somewhat needed.) - 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] fix abs() macro to work with types wider than int
> > > I think it's like it is just to be consistent with abs() in C, > > > which also contains labs() and llabs(). > > > > > We actually had labs() before (few months ago), but since it was not > > used, and if it would it seemed better to just fix abs(), it was > > removed. So I think this is the appropriate way to go. > > Sounds like when someone actually needs labs() or llabs() > they can submit a patch for however they would like to use it. However they would like to use *abs()? What different ways are possible to take the arithmetic absolute value? I see record of many cases where dozens of authors have macros that then get collapsed to include files. So why not avoid that annoyance this time and -start- with it in the include files? Can there even be any reason beyond unnecessary pedantics to have [l[l]]abs? - 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] fix abs() macro to work with types wider than int
> > Can there even be any reason beyond unnecessary pedantics to have [l[l]]abs? > > See Paragraph 1 above. We do lots of functions in a manner that is > like C (or libc) so that we don't confuse developers. I have the perfect solution that includes compatibility while avoiding stupidity. Macro "abs" which evaluates its argument once and uses typeof(). #define labs(n) abs(n) #define llabs(n) labs(n) Leave that in the kernel for a year or two. At the end of that time, grep the kernel to show that only two silly people actually use them. Change those, and remove the aliases. Sense restored. As far as I'm concerned, the only reason those functions exist like that is because standard C doesn't support function overloading and doesn't want to promote every argument to the biggest width and -also- can't define it as a macro because there's no typeof() in standard C. So since we do have it... ...and why do we want people hacking the kernel who get confused by a single "abs" function? Isn't that quite a lot like saying "Do not use hairdryer while sleeping."? - 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: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)
> One thing to try out (and dammit, I should make it the default now in > 2.6.21) is to just make the dirty limits much lower. We've been talking > about this for ages, I think this might be the right time to do it. Could[/should] this stuff be changed from ratios to amounts? Or a quick boot-time test to use a ratio if the memory is small and an amount (like tax brackets, I would expect) if it's great? - 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] lib/kobject_uevent.c: Collapse unnecessary loop nesting (top_kobj)
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
Collapses a do..while() loop within an if() to a simple while() loop for
simplicity and readability.
Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
---
I'm sure GCC is able to handle this optimization decently, but there's no
reason at all for the additional nesting level for the loop.
--- linux-2.6.20.4/lib/kobject_uevent.c.orig2007-04-04 07:25:08.0
-0400
+++ linux-2.6.20.4/lib/kobject_uevent.c 2007-04-04 07:27:28.0 -0400
@@ -95,10 +95,8 @@ int kobject_uevent_env(struct kobject *k
/* search the kset we belong to */
top_kobj = kobj;
- if (!top_kobj->kset && top_kobj->parent) {
- do {
- top_kobj = top_kobj->parent;
- } while (!top_kobj->kset && top_kobj->parent);
+ while (!top_kobj->kset && top_kobj->parent) {
+ top_kobj = top_kobj->parent;
}
if (!top_kobj->kset) {
pr_debug("kobject attempted to send uevent without kset!\n");
-
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: condingstyle, was Re: utrace comments
> > if (veryverylengthycondition1 &&
> > smallcond2 &&
> > (conditionnumber3a ||
> > condition3b)) {
> > ...
> > }
>
> It's horrid. I'd much rather see
>
> if (veryverylengthycondition1 &&
> smallcond2 &&
> (conditionnumber3a || condition3b)) {
> ...
> }
if (veryverylengthycondition1
&& smallcond2
&& (conditionnumber3a
|| condition3b)) {
...
}
Clear, crisp, and 80-wide. I also like how the logical operator on the
following line is indented slightly into the condition of the previous
line. I think this is much more sensical and sensible than using spaces to
line them up with the parentheses. Makes clear for each operator the
condition to which it applies.
-
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] crypto: convert "crypto" subdirectory to UTF-8
> > Convert the subdirectory "crypto" to UTF-8. The files changed are > > and . > > > > Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]> > > Thanks. Could you fix up include/linux/crypto.h as well? Sure, will do. Since I've gotten almost no feedback about these patches whatsoever, I figured either I was doing it wrong or nobody cared. I guess I'll finish them all up and resubmit them and hope they stick. Gimme a few days: There's a huge number of files throughout the tree to change, and some of them (like the .map files) require non-trivial alterations. (Were you able to successfully apply the patch attached in octet-stream encoding?) - 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: so ... what *are* candidates for removal?
> >> Regarding features that are overdue for removal according to > >> feature-removal-schedule.txt: > >> > >> I remember that at least one person used to watch for due dates for > >> feature removal, wrote the removing patches, and sent them to the > >> appropriate lists and maintainers. This either got rid of the > >> obsolete stuff, or it turned up reasons why some feature could not > >> be removed just yet and how to update feature-removal-schedule.txt > >> to correctly reflect that. > >> > >> So, as they say, Patches Are Welcome. > > > > that's a nice idea, but it doesn't address the problem that someone > > might go to the trouble to create such a patch and send it in, only to > > have that submission generate shrieking along the lines of "OHMIGOD, > > we can't delete that *yet*!!!" > > You are absolutely right. > > We have to try to avoid this waste of resources when we put features > into feature-removal-schedule.txt. That's what I meant with "the hard > part" in the other post. > > BTW, of course it doesn't suffice to say "we can't remove it yet" after > the due day. There need to be well-founded reasons for another > deferral. Of course if there are such reasons, it means something went > wrong when the feature was put into removal schedule. (Some facts > weren't known.) So when this sort of thing comes up, why can't somebody put together a trivial patch to update feature-removal-schedule.txt? If a deadline is reached, and a removal is attempted and aborted, the deadline should be extended, obviously. So then the patches can be resubmitted (or recreated, even) when the new deadline is reached, da capo. - 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] crypto: convert crypto.h to UTF-8
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]> Convert the encoding of from ISO-8859-1 to UTF-8. Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]> --- Did this file individually, per request. Will re-do the whole tree later as I'm still working on my handy-dandy testing and patching tools and don't have a lot of time outside of work until the summer gets underway. The patch works in ISO-8859-1 encoding. If I am unsuccessful in getting this mail to send as that, or if your viewer reinterprets it from that, you'll need to use the file attached as MIME type octet-stream. Thanks for your time and interest. --- linux-2.6.21-rc7-git4.orig/include/linux/crypto.h 2007-04-20 20:22:13.0 -0400 +++ linux-2.6.21-rc7-git4.mod/include/linux/crypto.h2007-05-03 07:09:47.0 -0400 @@ -6,7 +6,7 @@ * Copyright (c) 2005 Herbert Xu <[EMAIL PROTECTED]> * * Portions derived from Cryptoapi, by Alexander Kjeldaas <[EMAIL PROTECTED]> - * and Nettle, by Niels Möller. + * and Nettle, by Niels Möller. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the Free include-linux-crypto-h-to-utf8.patch.bin Description: Binary data
Re: [PATCH] crypto: convert crypto.h to UTF-8
> > Did this file individually, per request. Will re-do the whole tree later > > as I'm still working on my handy-dandy testing and patching tools and > > don't have a lot of time outside of work until the summer gets underway. > > While this is probably inevitable, it would be nice if there was some > way to determine the actual coding system used for individual files. > Especially if we're mixing latin1 and utf8 in the same tree. Has > something like adding "/* -*- coding: utf-8; -*- */" or similar to the > top of converted files been considered? There's no reason for any non-UTF-8 to be in the tree at all, so eventually it won't be a problem. I'm (slowly but surely) working on converting everything in the tree. GCC handles UTF-8 just fine, and all non-stupid/non-broken distributions of GNU/Linux and other major Un*ces should be based on (or at least compatible with) UTF-8 in basic operations. Files like the keymaps will be more work to convert, but they can be as well. I'm operating on the assumption that anything in the tree that isn't UTF-8 is ISO-8859-1. Of course, I'm also checking it by hand to make sure a small-O-with-umlaut doesn't become the Klingon logo... Besides, based on the actual binary representation of UTF-8, it's extremely unlikely for any ISO-8859-1 string to be detected as UTF-8. VIm already does this: UTF-8 it handles natively, but open up one of these unpatched files in VIm and you'll see "[converted]" at the bottom of your screen. Should happen if you open the attached .patch.bin file in VIm. - 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] crypto: convert crypto.h to UTF-8
> > Besides, based on the actual binary representation of UTF-8, it's > > extremely unlikely for any ISO-8859-1 string to be detected as UTF-8. VIm > > already does this: UTF-8 it handles natively, but open up one of these > > unpatched files in VIm and you'll see "[converted]" at the bottom of your > > screen. Should happen if you open the attached .patch.bin file in VIm. > > Yes, I agree that heuristics can be used to determine the coding > system used with a high degree of probability. I'm just suggesting we > make the coding system explicit, in order to spare other applications > that do visual presentation of Linux source code having to perform > their own heuristics. > > But hey, if I'm the only one wanting to see this particular bike shed > painted blue... In any other case, I would agree completely, but like I said, the entire tree will be one encoding anyway, which will be UTF-8. Many tools would already have these heuristics, and even if they don't, the code itself will be perfectly legible no matter which encoding is used to view it, and only some things like circuit diagrams and peoples' names may be slightly mangled. Any byte which is 0x7F or less is identical in both encodings, so all normal ASCII is unchanged. It's an issue only in transition. No new non-UTF-8 patches should be accepted, of course. And I won't be doing any changes that break anything other than a live person reading it and wondering why it looks weird if they don't have the right tools. A line in explicitly requiring UTF-8 sounds like a good idea. I shall submit one later if I remember. Many mail clients do this conversion automatically, which causes me headaches and requires me to attach the patches separately. Quite annoying really. I'm exploring the possibility of hacking together a simple SMTP client if that'll help me with these fool binary patches. Or maybe setting up a little mini git repository with UTF-8 changes is a good idea? Hmm, I'll research that, and try it. Then I could just cc it to trivial and the list and they can just pull it in one go. One more week until summer vacation! I shall have time to do this then. - 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] crypto: convert crypto.h to UTF-8
> >There's no reason for any non-UTF-8 to be in the tree at all, so > >eventually it won't be a problem. I'm (slowly but surely) working on > >converting everything in the tree. GCC handles UTF-8 just fine, and all > > In fact, GCC gives a crap about comments :) > and otherwise sees things as octets, not characters. > I think GCJ is the only one that really pays attention to encoding. The changes to the keymap files and so forth aren't quite as simple though. Have to convert the latin1 characters within character-constant expressions to \0 notation, while the comments can be left as utf8. > >non-stupid/non-broken distributions of GNU/Linux and other major Un*ces > >should be based on (or at least compatible with) UTF-8 in basic > >operations. Files like the keymaps will be more work to convert, but they > >can be as well. > > > >I'm operating on the assumption that anything in the tree that isn't UTF-8 > >is ISO-8859-1. Of course, I'm also checking it by hand to make sure a > >small-O-with-umlaut doesn't become the Klingon logo... > > This is probably all you'll ever see: > http://lkml.org/lkml/2007/1/8/222 Does this mean you're doing it and I'll be ignored, or that few people care and I'll be ignored? I figure if I just repost my patches to LKML once per month, they'll eventually get merged (or at least I'll get comments on how people actually want them). Things are tough on a high-volume list. I think the git method may have the best chance of success. We'll 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/
