> 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
> > 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,
> > 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
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
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
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
> > > > > 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
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
> > > + * 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
> + * 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
> > 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
> >> +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
+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
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
+ * 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
+ * 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
> > 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
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
> 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 +
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 +
+++
> 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
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
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?
>
>
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
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
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
> 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"
> >
> >
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
> > 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.
> >
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
> >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
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
> 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,
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
> > > 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,
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
> >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
> > 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
> > 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
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-d
From: John Anthony Kazos Jr. [EMAIL PROTECTED]
Convert the encoding of include/linux/crypto.h 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
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
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
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,
> >> 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
> > 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 almo
Convert the subdirectory crypto to UTF-8. The files changed are
crypto/fcrypt.c and crypto/api.c.
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
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
> > if (veryverylengthycondition1 &&
> > smallcond2 &&
> > (conditionnumber3a ||
> > condition3b)) {
> > ...
> > }
>
> It's horrid. I'd much rather see
>
> if (veryverylengthycondition1 &&
> smallcond2 &&
>
if (veryverylengthycondition1
smallcond2
(conditionnumber3a ||
condition3b)) {
...
}
It's horrid. I'd much rather see
if (veryverylengthycondition1
smallcond2
> 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
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
> > 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.
> > > 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
> 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
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 the
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
> > > 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>
> > >
> 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 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__bio_add_page: 2x ph 88=128 || hw 88=88 || 360448max
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
include/linux/kernel.h 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
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
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:
> > >
> > > > >
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
From: John Anthony Kazos Jr. [EMAIL PROTECTED]
Add helper functions upper_32_bits and lower_32_bits to
include/linux/kernel.h 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
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]
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]
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
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 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 patc
> > 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
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
> > 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
> 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" (?)
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-s
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
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
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
From: John Anthony Kazos Jr. [EMAIL PROTECTED]
Convert the kernel subdirectory of the tree to UTF-8. The only file
modified is kernel/sys.c.
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
From: John Anthony Kazos Jr. [EMAIL PROTECTED]
Convert the subdirectory crypto to UTF-8. The files changed are
crypto/fcrypt.c and crypto/api.c.
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
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
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
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
> 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
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
> > 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
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
> >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
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
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 &q
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 fun
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
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
(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
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
1 - 100 of 118 matches
Mail list logo
