Change the description of CONFIG_*HIGHMEM* to reflect "lost" memory due to
PCI space and the existence of the NX flag.
Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>
---
I made this quick patch using the information from LKML as I remembered
it. Please verify.
--- 2.6.21/arch/
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> On Mon, 04 Jun 2007, Dmitry Torokhov wrote:
>> >...but I'm not quite sure it is a buggy keyboard. It happens _way_ too
>> >often. Launch the line above and try to do some typing...
>>
>> This used to work fine on my box last time I tried
Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
On Mon, 04 Jun 2007, Dmitry Torokhov wrote:
...but I'm not quite sure it is a buggy keyboard. It happens _way_ too
often. Launch the line above and try to do some typing...
This used to work fine on my box last time I tried it (the switch
Change the description of CONFIG_*HIGHMEM* to reflect lost memory due to
PCI space and the existence of the NX flag.
Signed-Off-By: Bodo Eggert [EMAIL PROTECTED]
---
I made this quick patch using the information from LKML as I remembered
it. Please verify.
--- 2.6.21/arch/i386/Kconfig.ori
Tejun Heo <[EMAIL PROTECTED]> wrote:
> David Greaves wrote:
>> I have 2 ide disks. If I enable SMART and hibernate/suspend2disk, SMART is
>> disabled when I resume.
Maybe it's disabled by the BIOS?
> According to the ATA standard, the device (drive) itself is responsible
> for preserving
Tejun Heo [EMAIL PROTECTED] wrote:
David Greaves wrote:
I have 2 ide disks. If I enable SMART and hibernate/suspend2disk, SMART is
disabled when I resume.
snip
Maybe it's disabled by the BIOS?
According to the ATA standard, the device (drive) itself is responsible
for preserving SMART
Uncle George <[EMAIL PROTECTED]> wrote:
> i am using the GARMIN_GPS/usb driver to read a gps receiver.
> In testing the ability of my software to recover from various errors, I
> try this: unplug the gps/USB cable from the usb hub.
>
> Interestingly enough the thread spins.
> the SELECT() waits
Uncle George [EMAIL PROTECTED] wrote:
i am using the GARMIN_GPS/usb driver to read a gps receiver.
In testing the ability of my software to recover from various errors, I
try this: unplug the gps/USB cable from the usb hub.
Interestingly enough the thread spins.
the SELECT() waits for
On Sat, 26 May 2007, Al Viro wrote:
> On Sat, May 26, 2007 at 06:38:07PM +0200, Bodo Eggert wrote:
> > Not exactly, if(foo) is the same as if( (int) foo), which is not
> > guaranteed to result in non-null values for non-null pointers.
>
> RTFStandard.
... and don´t forget
On Sat, 26 May 2007, Al Viro wrote:
On Sat, May 26, 2007 at 06:38:07PM +0200, Bodo Eggert wrote:
Not exactly, if(foo) is the same as if( (int) foo), which is not
guaranteed to result in non-null values for non-null pointers.
RTFStandard.
... and don´t forget half of it untill you look up
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> On May 25 2007 14:14, David Miller wrote:
>>"!!" is used in contexts where pointers might be being
>>tested as well as plain integers, the "!!" turns a pointer
>>into the equivalent integer boolean for testing.
>>
>>NULL pointers become 0
>>non-NULL
Jan Engelhardt [EMAIL PROTECTED] wrote:
On May 25 2007 14:14, David Miller wrote:
!! is used in contexts where pointers might be being
tested as well as plain integers, the !! turns a pointer
into the equivalent integer boolean for testing.
NULL pointers become 0
non-NULL pointers become 1
Satyam Sharma <[EMAIL PROTECTED]> wrote:
> In fact you can't really say the same for
> volatile. We already assume the compiler _actually_ took some
> pains to stuff meaning into C's (lack of) definition of volatile and
> implement it -- but in what sense, nobody knows (the C standard
Satyam Sharma [EMAIL PROTECTED] wrote:
In fact you can't really say the same for
volatile. We already assume the compiler _actually_ took some
pains to stuff meaning into C's (lack of) definition of volatile and
implement it -- but in what sense, nobody knows (the C standard
Albert Cahalan <[EMAIL PROTECTED]> wrote:
> On 5/9/07, Andrey Borzenkov <[EMAIL PROTECTED]> wrote:
>> 3. this still does not answer how can I *create* long name from within Linux.
>
> WTF? These names are too annoying to use, even if there
> weren't this limit. Anything over about 29 characters
Albert Cahalan [EMAIL PROTECTED] wrote:
On 5/9/07, Andrey Borzenkov [EMAIL PROTECTED] wrote:
3. this still does not answer how can I *create* long name from within Linux.
WTF? These names are too annoying to use, even if there
weren't this limit. Anything over about 29 characters is in
Albert Cahalan <[EMAIL PROTECTED]> wrote:
[...]
> At two bytes per character, you get 127 characters in a filename.
> That's wider than the standard 80-column display, and far wider
> than the 28 or 29 characters that an "ls -l" has room for. In a
> GUI file manager or file dialog box, you'll
Albert Cahalan [EMAIL PROTECTED] wrote:
[...]
At two bytes per character, you get 127 characters in a filename.
That's wider than the standard 80-column display, and far wider
than the 28 or 29 characters that an ls -l has room for. In a
GUI file manager or file dialog box, you'll have to
Jörn Engel <[EMAIL PROTECTED]> wrote:
> On Fri, 4 May 2007 10:46:10 +0100, Christoph Hellwig wrote:
>> Which means the right place to fix this is samba. Samba just need
>> to intersept lseek and pread/pwrite to never allocate sparse files
>> but do the right thing instead. Now what the right
Jörn Engel [EMAIL PROTECTED] wrote:
On Fri, 4 May 2007 10:46:10 +0100, Christoph Hellwig wrote:
Which means the right place to fix this is samba. Samba just need
to intersept lseek and pread/pwrite to never allocate sparse files
but do the right thing instead. Now what the right thing would
Robin Getz <[EMAIL PROTECTED]> wrote:
> On Fri 4 May 2007 16:52, Robert Schwebel pondered:
>> On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
>> > We also have DAC and ADC drivers (up to 16 bits @ 64MS/s, via DMA),
>> > that would be nice to put in the "right" place - I don't think
Robin Getz [EMAIL PROTECTED] wrote:
On Fri 4 May 2007 16:52, Robert Schwebel pondered:
On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
We also have DAC and ADC drivers (up to 16 bits @ 64MS/s, via DMA),
that would be nice to put in the right place - I don't think that
Theodore Tso <[EMAIL PROTECTED]> wrote:
> But as has already been discussed on this thread, in situations where
> the fileserver is under high memory pressure, any filesystem (XFS or
> ext4) would still end up allocating blocks out of order, resulting in
> fragmentation. Explicit preallocation,
Theodore Tso [EMAIL PROTECTED] wrote:
But as has already been discussed on this thread, in situations where
the fileserver is under high memory pressure, any filesystem (XFS or
ext4) would still end up allocating blocks out of order, resulting in
fragmentation. Explicit preallocation, as
Some Kconfig menus are very unsorted, so finding the option you want to
change takes careful reading of the complete menu.
I'm about to change some of the menus to be more user-friendly, starting
with the general setup and working my way through the rest as time permits.
In order to make the
Some Kconfig menus are very unsorted, so finding the option you want to
change takes careful reading of the complete menu.
I'm about to change some of the menus to be more user-friendly, starting
with the general setup and working my way through the rest as time permits.
In order to make the
Pavel Machek <[EMAIL PROTECTED]> wrote:
>> I also don't like the idea of storing this in the swap partition for a
>> couple of reasons.
>>
>> 1. on many modern linux systems the swap partition is not large enough.
>>
>> for example, on my boxes with 16G or ram I only allocate 2G of swap
>>
Pavel Machek [EMAIL PROTECTED] wrote:
I also don't like the idea of storing this in the swap partition for a
couple of reasons.
1. on many modern linux systems the swap partition is not large enough.
for example, on my boxes with 16G or ram I only allocate 2G of swap
space
WTF? So
On Sun, 22 Apr 2007, OGAWA Hirofumi wrote:
> Bodo Eggert <[EMAIL PROTECTED]> writes:
> > Windows _does_ care*, it will pretend the disk to be full.
>
> Did you test on 2000 or XP? (e.g. write 0 to free_clusters, then
> create new file.)
That was back when I still
OGAWA Hirofumi <[EMAIL PROTECTED]> wrote:
> DervishD <[EMAIL PROTECTED]> writes:
>> Probably it's stupid to update the free clusters count at mount time
>> (sorry if so...) but it looks like a good idea to me. And of course, I
>> don't mean to update the value _on disk_, but the kernel's idea
OGAWA Hirofumi <[EMAIL PROTECTED]> wrote:
>> * Juergen Beisert <[EMAIL PROTECTED]> dixit:
>>> So the last free sector count is also stored. When mounting this
>>> filesystem you don't need to walk through the whole FAT to calculate
>>> the available space, you can use this "cached" value
OGAWA Hirofumi [EMAIL PROTECTED] wrote:
* Juergen Beisert [EMAIL PROTECTED] dixit:
So the last free sector count is also stored. When mounting this
filesystem you don't need to walk through the whole FAT to calculate
the available space, you can use this cached value instead. And this
OGAWA Hirofumi [EMAIL PROTECTED] wrote:
DervishD [EMAIL PROTECTED] writes:
Probably it's stupid to update the free clusters count at mount time
(sorry if so...) but it looks like a good idea to me. And of course, I
don't mean to update the value _on disk_, but the kernel's idea of free
On Sun, 22 Apr 2007, OGAWA Hirofumi wrote:
Bodo Eggert [EMAIL PROTECTED] writes:
Windows _does_ care*, it will pretend the disk to be full.
Did you test on 2000 or XP? (e.g. write 0 to free_clusters, then
create new file.)
That was back when I still used W98.
- usefree is a bad name
Rene Herman <[EMAIL PROTECTED]> wrote:
> On 04/19/2007 04:18 PM, Bart Trojanowski wrote:
>> I need to preserve some state from the bios before entering protected
>> mode. For now I want to copy it into some ram accessible by real-mode,
>> say the last megabyte visible in real-mode.
>>
>> What's
Rene Herman [EMAIL PROTECTED] wrote:
On 04/19/2007 04:18 PM, Bart Trojanowski wrote:
I need to preserve some state from the bios before entering protected
mode. For now I want to copy it into some ram accessible by real-mode,
say the last megabyte visible in real-mode.
What's the easiest
Tejun Heo <[EMAIL PROTECTED]> wrote:
> This really isn't a regression. It's been always like that with libata.
> libata doesn't make devices go into standby mode and shutdown(8) does
> it for libata. The problem here is that libata does issue
> SYNCHRONIZE_CACHE on shutdown. So, the sequence
Tejun Heo [EMAIL PROTECTED] wrote:
This really isn't a regression. It's been always like that with libata.
libata doesn't make devices go into standby mode and shutdown(8) does
it for libata. The problem here is that libata does issue
SYNCHRONIZE_CACHE on shutdown. So, the sequence of
vjn <[EMAIL PROTECTED]> wrote:
> in my project i want to code the kernel such that when i plugged my usb it
> should ask for password and check it in the kernel space . can anyone help
> me
No, since the kernel has no way to ask for input. Imagine a two-seated
machine with two keyboards, mice
vjn [EMAIL PROTECTED] wrote:
in my project i want to code the kernel such that when i plugged my usb it
should ask for password and check it in the kernel space . can anyone help
me
No, since the kernel has no way to ask for input. Imagine a two-seated
machine with two keyboards, mice and
Ethan Solomita <[EMAIL PROTECTED]> wrote:
> I suggest a variant on what Andrew says: don't change reclaim.
> Instead, when referencing a page, don't mark the page as referenced if
> the current task is not permitted to allocate from the page's node. I'm
> thinking in terms of cpusets, with
Ethan Solomita [EMAIL PROTECTED] wrote:
I suggest a variant on what Andrew says: don't change reclaim.
Instead, when referencing a page, don't mark the page as referenced if
the current task is not permitted to allocate from the page's node. I'm
thinking in terms of cpusets, with each
Kumar Gala <[EMAIL PROTECTED]> wrote:
> For source lines I've seen both:
>
> source "arch/powerpc/platforms/52xx/Kconfig"
>
> and
>
> source arch/powerpc/platforms/85xx/Kconfig
>
> Is there a preferred style? Quotes or not?
$ find . -name Kconfig -exec grep ^source '{}' \;|grep \"|wc -l
Kumar Gala [EMAIL PROTECTED] wrote:
For source lines I've seen both:
source arch/powerpc/platforms/52xx/Kconfig
and
source arch/powerpc/platforms/85xx/Kconfig
Is there a preferred style? Quotes or not?
$ find . -name Kconfig -exec grep ^source '{}' \;|grep \|wc -l
732
$ find .
On Mon, 12 Mar 2007, Michael K. Edwards wrote:
> On 3/12/07, Bodo Eggert <[EMAIL PROTECTED]> wrote:
> > Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> > > Actually, I think it would make the kernel (negligibly) faster to bump
> > > f_pos before the vfs_w
Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> On 3/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
>> Absolutely not. We dont want to slow down kernel 'just in case a fool might
>> want to do crazy things'
>
> Actually, I think it would make the kernel (negligibly) faster to bump
> f_pos before
Michael K. Edwards [EMAIL PROTECTED] wrote:
On 3/8/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Absolutely not. We dont want to slow down kernel 'just in case a fool might
want to do crazy things'
Actually, I think it would make the kernel (negligibly) faster to bump
f_pos before the
On Mon, 12 Mar 2007, Michael K. Edwards wrote:
On 3/12/07, Bodo Eggert [EMAIL PROTECTED] wrote:
Michael K. Edwards [EMAIL PROTECTED] wrote:
Actually, I think it would make the kernel (negligibly) faster to bump
f_pos before the vfs_write() call.
This is a security risk.
snip
I
Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> On Sat, Mar 10, 2007 at 10:34:41PM +0100, Jan Engelhardt wrote:
>> On Mar 10 2007 22:27, Sam Ravnborg wrote:
>> >On Sat, Mar 10, 2007 at 07:23:41PM +0100, Jan Engelhardt wrote:
>> >> Whether the 'working config file path' should change when you do
>> >>
Sam Ravnborg [EMAIL PROTECTED] wrote:
On Sat, Mar 10, 2007 at 10:34:41PM +0100, Jan Engelhardt wrote:
On Mar 10 2007 22:27, Sam Ravnborg wrote:
On Sat, Mar 10, 2007 at 07:23:41PM +0100, Jan Engelhardt wrote:
Whether the 'working config file path' should change when you do
'Save as
On Wed, 7 Mar 2007, Jean Delvare wrote:
> On Tue, 6 Mar 2007 21:40:19 +0100 (CET), Bodo Eggert wrote:
> > 1) I asume port allocations or ACPI foreign port acces to be rare, so
> >there would be little impact on (un)registering hardware. Off cause
> >there are some
On Wed, 7 Mar 2007, Jean Delvare wrote:
On Tue, 6 Mar 2007 21:40:19 +0100 (CET), Bodo Eggert wrote:
1) I asume port allocations or ACPI foreign port acces to be rare, so
there would be little impact on (un)registering hardware. Off cause
there are some long ACPI calls (like reading
On Tue, 6 Mar 2007, Jean Delvare wrote:
> On Mon, 05 Mar 2007 14:56:44 +0100, Bodo Eggert wrote:
> > 2) make ACPI take this lock whenever it touches ports not allocated by
> > itself
> >and release it on function return.
>
> This is costly.
TANSTAAFL. Yo
On Tue, 6 Mar 2007, Jean Delvare wrote:
On Mon, 05 Mar 2007 14:56:44 +0100, Bodo Eggert wrote:
2) make ACPI take this lock whenever it touches ports not allocated by
itself
and release it on function return.
This is costly.
TANSTAAFL. You'll need to take some lock, and if you want
David Hubbard <[EMAIL PROTECTED]> wrote:
> For I/O and memory that ACPI accesses and has not reserved, the AML
> interpreter could allocate at run-time.
>
> I'm not sure how to implement exactly. For example, it would be bad to
> have a /proc/ioports that had a lot of single ports allocated, for
David Hubbard [EMAIL PROTECTED] wrote:
For I/O and memory that ACPI accesses and has not reserved, the AML
interpreter could allocate at run-time.
I'm not sure how to implement exactly. For example, it would be bad to
have a /proc/ioports that had a lot of single ports allocated, for
Rik van Riel <[EMAIL PROTECTED]> wrote:
+++ linux-2.6.20.noarch/mm/swap.c2007-02-20 06:44:17.0 -0500
@@ -420,6 +420,26 @@ void pagevec_strip(struct pagevec *pvec)
> +if (printk_ratelimit())
> +printk("kswapd freed a swap
Rik van Riel [EMAIL PROTECTED] wrote:
+++ linux-2.6.20.noarch/mm/swap.c2007-02-20 06:44:17.0 -0500
@@ -420,6 +420,26 @@ void pagevec_strip(struct pagevec *pvec)
+if (printk_ratelimit())
+printk(kswapd freed a swap
On Fri, 16 Feb 2007, Sergei Organov wrote:
> Bodo Eggert <[EMAIL PROTECTED]> writes:
> > Sergei Organov <[EMAIL PROTECTED]> wrote:
> >> Linus Torvalds <[EMAIL PROTECTED]> writes:
> > If you don't code for a specific compiler with specific setting
Roman Zippel <[EMAIL PROTECTED]> wrote:
> On Thu, 15 Feb 2007, David Howells wrote:
>> > This is really the weak point - it offers no advantage over an equivalent
>> > implementation in user space (e.g. in the module tools). So why has to be
>> > done in the kernel?
>>
>> Because the
On Fri, 16 Feb 2007, Sergei Organov wrote:
> Bodo Eggert <[EMAIL PROTECTED]> writes:
> > Sergei Organov <[EMAIL PROTECTED]> wrote:
> >> Linus Torvalds <[EMAIL PROTECTED]> writes:
> [...]
> > Using signed chars for strings is wrong in most countries on
On Fri, 16 Feb 2007, Sergei Organov wrote:
Bodo Eggert [EMAIL PROTECTED] writes:
Sergei Organov [EMAIL PROTECTED] wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
[...]
Using signed chars for strings is wrong in most countries on earth. It was
wrong when the first IBM PC came out in 1981
On Fri, 16 Feb 2007, Sergei Organov wrote:
Bodo Eggert [EMAIL PROTECTED] writes:
Sergei Organov [EMAIL PROTECTED] wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
If you don't code for a specific compiler with specific settings, there is
no implementation defining the signedness of char
Roman Zippel [EMAIL PROTECTED] wrote:
On Thu, 15 Feb 2007, David Howells wrote:
This is really the weak point - it offers no advantage over an equivalent
implementation in user space (e.g. in the module tools). So why has to be
done in the kernel?
Because the init_module() system call
v j <[EMAIL PROTECTED]> wrote:
> So far I have heard nothing but, "if you don't contribute, screw you."
That's exactly what you tell to the linux community: If they don't contribute
to your project *FOR*NOTHING*IN*RETURN*, you'll punish them by - stamping
your feet, crying out loud and *paying*
Sergei Organov <[EMAIL PROTECTED]> wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>> Exactly because "char" *by*definition* is "indeterminate sign" as far as
>> something like "strlen()" is concerned.
>
> Thanks, I now understand that you either don't see the difference
> between
Andi Kleen <[EMAIL PROTECTED]> wrote:
> Now if it's better to set up a empty node or use a nearby node
> for a memory less cpu can be further discussed. I still think
> I lean towards the later.
Worst case: Only slot 0 is used. Plug your memoryless CPU card into the last
slot before your plug
v j <[EMAIL PROTECTED]> wrote:
> On 2/14/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>> On Wed, 2007-02-14 at 21:16 -0800, v j wrote:
>> > This is in reference to the following thread:
>> >
>> > http://lkml.org/lkml/2006/12/14/63
>> >
>> > I am not sure if this is ever addressed in LKML, but
v j [EMAIL PROTECTED] wrote:
On 2/14/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
On Wed, 2007-02-14 at 21:16 -0800, v j wrote:
This is in reference to the following thread:
http://lkml.org/lkml/2006/12/14/63
I am not sure if this is ever addressed in LKML, but linux is _very_
Andi Kleen [EMAIL PROTECTED] wrote:
Now if it's better to set up a empty node or use a nearby node
for a memory less cpu can be further discussed. I still think
I lean towards the later.
Worst case: Only slot 0 is used. Plug your memoryless CPU card into the last
slot before your plug the
Sergei Organov [EMAIL PROTECTED] wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
Exactly because char *by*definition* is indeterminate sign as far as
something like strlen() is concerned.
Thanks, I now understand that you either don't see the difference
between indeterminate and
v j [EMAIL PROTECTED] wrote:
So far I have heard nothing but, if you don't contribute, screw you.
That's exactly what you tell to the linux community: If they don't contribute
to your project *FOR*NOTHING*IN*RETURN*, you'll punish them by - stamping
your feet, crying out loud and *paying* for
Al Boldi <[EMAIL PROTECTED]> wrote:
> Doing the following results in an incomplete vmlinuz:
> # make bzlilo
>
> objcopy: arch/i386/boot/compressed/vmlinux.bin: File truncated
> make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 1
> make[1]: *** [arch/i386/boot/compressed/vmlinux] Error
On Sat, 3 Feb 2007, Alan wrote:
> Bodo Eggert <[EMAIL PROTECTED]> wrote:
> > This patch changes the module license handling code to:
> > - allow modules to have multiple licenses
>
> NAK
I still think it would be a good idea, but if too many people misinterpre
On Sat, 3 Feb 2007, Alan wrote:
Bodo Eggert [EMAIL PROTECTED] wrote:
This patch changes the module license handling code to:
- allow modules to have multiple licenses
NAK
I still think it would be a good idea, but if too many people misinterpret
my concept, you can't do
Al Boldi [EMAIL PROTECTED] wrote:
Doing the following results in an incomplete vmlinuz:
# make bzlilo
objcopy: arch/i386/boot/compressed/vmlinux.bin: File truncated
make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 1
make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2
make:
On Sat, 3 Feb 2007, Jan Engelhardt wrote:
> On Feb 3 2007 03:08, Bodo Eggert wrote:
> >This patch changes the module license handling code to:
> >- allow modules to have multiple licenses
> >- access GPL symbols if at least one license is GPL-compatible
>
> I strong
On Sat, 3 Feb 2007, Jan Engelhardt wrote:
On Feb 3 2007 03:08, Bodo Eggert wrote:
This patch changes the module license handling code to:
- allow modules to have multiple licenses
- access GPL symbols if at least one license is GPL-compatible
I strongly nak that. If you combine two object
es)
- move the ndiswrapper check into the new license checking routine
Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>
---
The license handling code was kind of strange:
- The kernel itself would only consider the first license, while modpost
looks at all of them.
- If you offer your mo
the ndiswrapper check into the new license checking routine
Signed-Off-By: Bodo Eggert [EMAIL PROTECTED]
---
The license handling code was kind of strange:
- The kernel itself would only consider the first license, while modpost
looks at all of them.
- If you offer your module under a non-GPL
change pipefs to use a unique inode number equal to the memory
address unless it would be truncated.
Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>
---
Tested on i386.
--- 2.6.19/fs/pipe.c.ori2007-01-30 22:02:46.0 +0100
+++ 2.6.19/fs/pipe.c2007-01-30 23:22:27.0
Jeff Layton <[EMAIL PROTECTED]> wrote:
> This patch updates pipefs to do defer assigning an i_ino value to its inodes
> until someone actually tries to stat it. This allows us to have unique i_ino
> values for the inodes here, without the performance impact for anyone who
> doesn't actually care
Dave Jones <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 12, 2007 at 05:58:41PM -0500, [EMAIL PROTECTED] wrote:
> > jengelh> What: RAW driver (CONFIG_RAW_DRIVER)
> > jengelh> When: December 2005
> > jengelh> Why:declared obsolete since kernel 2.6.3
> > jengelh> O_DIRECT can
Dave Jones [EMAIL PROTECTED] wrote:
On Fri, Jan 12, 2007 at 05:58:41PM -0500, [EMAIL PROTECTED] wrote:
jengelh What: RAW driver (CONFIG_RAW_DRIVER)
jengelh When: December 2005
jengelh Why:declared obsolete since kernel 2.6.3
jengelh O_DIRECT can be used
Jeff Layton [EMAIL PROTECTED] wrote:
This patch updates pipefs to do defer assigning an i_ino value to its inodes
until someone actually tries to stat it. This allows us to have unique i_ino
values for the inodes here, without the performance impact for anyone who
doesn't actually care about
change pipefs to use a unique inode number equal to the memory
address unless it would be truncated.
Signed-Off-By: Bodo Eggert [EMAIL PROTECTED]
---
Tested on i386.
--- 2.6.19/fs/pipe.c.ori2007-01-30 22:02:46.0 +0100
+++ 2.6.19/fs/pipe.c2007-01-30 23:22:27.0 +0100
Eriberto <[EMAIL PROTECTED]> wrote:
> I am trying understand the swap. I would like to know which is the
> maximum swap size on i386. Is 64 MB? If yes, how to know the origin of
> this "magic" number? I don't found it (Internet).
Look into the manpage of mkswap. It's 2 G x 32 swap partitions,
Eriberto [EMAIL PROTECTED] wrote:
I am trying understand the swap. I would like to know which is the
maximum swap size on i386. Is 64 MB? If yes, how to know the origin of
this magic number? I don't found it (Internet).
Look into the manpage of mkswap. It's 2 G x 32 swap partitions,
minus a
Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> On Friday 26 January 2007 19:23, Bill Davidsen wrote:
>> Denis Vlasenko wrote:
>> > On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
>> >> But even single-threaded I/O but in large quantities benefits from
>> >> O_DIRECT significantly, and I
Fengguang Wu <[EMAIL PROTECTED]> wrote:
> The new/old ra class were implicitly stored in low bits of
> file_ra_state.flags. Now make the data structure obvious, and remove the
> coding tricks.
> +++ linux-2.6.20-rc4-mm1/include/linux/fs.h
> - unsigned long flags;/* RA_FLAG_xxx |
Fengguang Wu [EMAIL PROTECTED] wrote:
The new/old ra class were implicitly stored in low bits of
file_ra_state.flags. Now make the data structure obvious, and remove the
coding tricks.
+++ linux-2.6.20-rc4-mm1/include/linux/fs.h
- unsigned long flags;/* RA_FLAG_xxx | ra_class_old |
Denis Vlasenko [EMAIL PROTECTED] wrote:
On Friday 26 January 2007 19:23, Bill Davidsen wrote:
Denis Vlasenko wrote:
On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
But even single-threaded I/O but in large quantities benefits from
O_DIRECT significantly, and I pointed this out
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-01-24 at 22:22 +0800, Aubrey Li wrote:
>> On 1/24/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>> > He wants to make a nommu system act like a mmu system; this will just
>> > never ever work.
>>
>> Nope. Actually my nommu system works
Scott Preece <[EMAIL PROTECTED]> wrote:
> My own hot button is making sure that the definition of what
> constitutes user activity is managed in exactly one place, whether in
> the kernel or not. My naive model would be to put the response at user
> level, but to provide a single point of
Scott Preece [EMAIL PROTECTED] wrote:
My own hot button is making sure that the definition of what
constitutes user activity is managed in exactly one place, whether in
the kernel or not. My naive model would be to put the response at user
level, but to provide a single point of definition in
Peter Zijlstra [EMAIL PROTECTED] wrote:
On Wed, 2007-01-24 at 22:22 +0800, Aubrey Li wrote:
On 1/24/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
He wants to make a nommu system act like a mmu system; this will just
never ever work.
Nope. Actually my nommu system works great with some of
On Mon, 22 Jan 2007, Tony Foiani wrote:
> > "Jan" == Jan Engelhardt <[EMAIL PROTECTED]> writes:
>
> Jan> For "F"s sake, when you gotta use abbreviations, then just use
> Jan> k=1000 and K=1024 already, b for bits and B for bytes. Problem
> Jan> gone.
>
>The one-letter abbreviations are
On Mon, 22 Jan 2007, Tony Foiani wrote:
Jan == Jan Engelhardt [EMAIL PROTECTED] writes:
Jan For Fs sake, when you gotta use abbreviations, then just use
Jan k=1000 and K=1024 already, b for bits and B for bytes. Problem
Jan gone.
The one-letter abbreviations are identical to SI
Tony Foiani <[EMAIL PROTECTED]> wrote:
>> "David" == David Schwartz <[EMAIL PROTECTED]> writes:
> Just last night I formatted some new "500GB" drives, and they
> eventually came back with 465GB as the displayed capacity. Wouldn't
> it make more sense to display that as "465GiB"?
[...]
>
Tony Foiani [EMAIL PROTECTED] wrote:
David == David Schwartz [EMAIL PROTECTED] writes:
Just last night I formatted some new 500GB drives, and they
eventually came back with 465GB as the displayed capacity. Wouldn't
it make more sense to display that as 465GiB?
[...]
David Adopting IEC
301 - 400 of 739 matches
Mail list logo
