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:
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 bod
> 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 +
> > 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 IO
> >> +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 affec
> > 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 pat
> + * 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 wh
> > > + * 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 s
> > > > > 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 signi
> >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 arti
> > 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.
> >
> 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///
> > 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 meanin
> > 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
> 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
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'v
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,
> 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 t
> 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 i
> 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" (?)
> > 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
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 oc
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
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
> > 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 usin
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_e
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 K
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]
Mo
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:
> > >
> > > > > CONF
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 ge
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 ge
> > > 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
> 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
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
ea
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]>
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/f
(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
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
r
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
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
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 prev
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 functi
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
> >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 resear
> > 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 sl
> 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
> > > 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>
> 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
> > > 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
> > 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.
Macr
> 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-ti
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 t
> > if (veryverylengthycondition1 &&
> > smallcond2 &&
> > (conditionnumber3a ||
> > condition3b)) {
> > ...
> > }
>
> It's horrid. I'd much rather see
>
> if (veryverylengthycondition1 &&
> smallcond2 &&
>
> > 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
> >> 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 eit
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-
> > 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
> > 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
> >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 o
59 matches
Mail list logo
