Re: [PATCH] unlock before bug returns

[Rene Herman]

On 10/22/2007 02:40 PM, Pekka Enberg wrote:


On 10/22/07, Roel Kluin [EMAIL PROTECTED] wrote:

diff --git a/mm/slab.c b/mm/slab.c
index cfa6be4..20c58dc 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1606,8 +1606,10 @@ void __init kmem_cache_init(void)
struct kmem_cache *cachep;
mutex_lock(cache_chain_mutex);
list_for_each_entry(cachep, cache_chain, next)
-   if (enable_cpucache(cachep))
+   if (enable_cpucache(cachep)) {
+   mutex_unlock(cache_chain_mutex);
BUG();
+   }
mutex_unlock(cache_chain_mutex);
}


NAK. This will cause double-unlock when CONFIG_BUG is disabled. It's
incorrect to assume that BUG() will always terminate the current
process.


(which by the way also means that the return; delete from your original 
patch changes behaviour for !CONFIG_BUG, and probably not for the better).


Rene.

-
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] return hidden bug

[Rene Herman]

On 10/22/2007 08:52 PM, Roel Kluin wrote:


Ray Lee wrote:



Arguing intentions is very dangerous. I've written code like that
where the intention is to make it simple to turn a printk into a full
bug and back and forth during development. At the end of the day, the
fact remains that you're changing behavior.

Let me turn this around. Do you have an alpha and have you tried out
your patch? If not, then I'd suggest turning it into a WARN_ON(1)
instead, as in this specific case you're risking turning what was a
working system into one that doesn't.


No, I haven't and, I will change it, but it's included with my other
changes. see the reply that I'll write shortly for.
[PATCH retry] return hidden bug and unlock bugs.


Hugely trust inspiring isn't it -- the amount of eyes and comments you'll 
get even on trivial patches like this? This development model is working!


Now if only we'd sometimes get some for non trivial patches as well...

Rene.
-
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] return hidden bug

[Rene Herman]

On 10/23/2007 01:00 AM, Ray Lee wrote:


On 10/22/07, Rene Herman [EMAIL PROTECTED] wrote:



Hugely trust inspiring isn't it -- the amount of eyes and comments you'll
get even on trivial patches like this? This development model is working!


Go easy with the snarkiness, hmm? It's the trivial ones that seem to
be the most dangerous. The larger ones actually get *tested*
sometimes.


I was also commenting and don't generally on anything much more involved so 
any snarkiness included myself which should make things better.



Now if only we'd sometimes get some for non trivial patches as well...


That's certainly true regardless, but for myself, I'd rather throw
some reviews out for the small ones since I have adequate time and
knowledge for them. The larger ones require domain specific knowledge
I lack, and time I don't have.


Exactly the problem. Comment was mostly triggered due to me looking at a 
problem with a proprietary CD-ROM driver again tonight that I posted a few 
months ago where the only comment has been from the fellow author. There the 
problem was the block layer blowing up and given that it seems unlikely that 
this wouldn't be a problem inside the newbie-driver itself, that the block 
part of it was actually really small and people said they'd look at it, the 
subsequent thundering silence still annoys me.


Ofcourse, now it seems the kernel itself has moved on enough that the driver 
doesn't work at _all_ anymore and I at the moment lack the time to spend the 
required hours googling around trying to find out what the heck changed out 
from under me so that I might get it to at least do what it already did do.


Hey, I don't actually know and maybe I'm just wrong but I have the feeling 
that over the last 1 or 2 years most new developers seem to be either people 
that are payed to be so, perhaps in the form of graduation, or janitors. The 
kernel is much, much more complex than even only a few years ago and at the 
same time the number of knowledgeable developers who'll do something other 
than their own thing and otherwise just wait around for something perfect to 
merge seems to be approaching zero.


That is -- I do not feel that the current developer base is expending overly 
many efforts to appear welcoming.


Please feel free to do the open-source thing and argue that's actually an 
advantage (there we have that snarkiness again...) or otherwise ignore me. 
I'll just sit here and be grumpy anyway. Might be better after a good 
night's sleep...


Rene.

-
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: ide=reverse do we still need this?

[Rene Herman]

On 13-02-08 01:15, Greg KH wrote:


I'm reworking the pci device list logic (we currently keep all PCI
devices in 2 lists, which isn't the nicest, we should be able to get
away with only 1 list.)

The only bother I've found so far is the pci_get_device_reverse()
function, it's used in 2 places, IDE and the calgary driver.

I'm curious if we really still support the ide=reverse option?  It's a
config option that I don't think the distros still enable (SuSE does
not).  Is this still needed these days?

In digging, we changed this option in 2.2.x from being called
pci=reverse and no one else seems to miss it.

Any thoughts?


While details escape me somewhat again at the monment, a few months ago I 
was playing around with a PCI Promise IDE controller and needed ide=reverse 
to save me from having to switch disks around to still have a bootable system.


Or some such. Not too clear anymore, but I remember it saved the day.

Rene.
--
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: BTRFS partition usage...

[Rene Herman]

On 13-02-08 00:42, Jan Engelhardt wrote:


x86 MSDOS partition table layout starts counting with sector 1, which is
(not so intuitively) starting at 0x7e00 (and there's no sector 0, 
probably for safety). Well, each ptable format with its own quirks.


I haven't followed this thread, but in case it matters -- this sounds fairly 
confused.


Not sure what you're saying, but the MSDOS partition table has its root 
table in the very first sector on the disk, at offset 0x1be = 0x200 - 4 * 
sizeof(struct partition) - 2 (that is, 4 entries at the end of that first 
sector, followed by a 2-byte signature).


That 0x7e00 that you are speaking of sounds somewhat like the _memory_ 
address the BIOS loads that first sector to: 0x7c00. It then jumps there to 
start the ball rolling but 0x7c00 is not an on-disk reality or anything.


MS-DOS partition tables are furthermore fully outside the actual partitions 
themselves and as such I believe not all together relevant to the issue? (as 
said, not following along though...)


Rene
--
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: ide=reverse do we still need this?

[Rene Herman]

On 13-02-08 13:16, Michael Ellerman wrote:


On Wed, 2008-02-13 at 13:06 +0100, Rene Herman wrote:

On 13-02-08 05:44, Greg KH wrote:


While details escape me somewhat again at the monment, a few months ago
I was playing around with a PCI Promise IDE controller and needed
ide=reverse to save me from having to switch disks around to still have
a bootable system.

Or some such. Not too clear anymore, but I remember it saved the day.

You couldn't just change the boot disk in grub?

Or use an initramfs and /dev/disk/by-id/ to keep any future moves stable?
No. The thing is that you need these kinds of hacks while messing with old 
systems, building and stripping them, often in recovery type of situations.


As said (same as the other person I saw reacting) details of what was most 
decidedly needed last time around escape me at the moment, but ide=reverse 
is the kind of hack that saves one hours of unscrewing computer cases and 
switching disks around while building stuff, making quick tests, doing 
recovery...


If it must go for the greater architectural good, so be it, but it's the 
type of thing that's used specifically in the situations where you don't 
have stable, well arranged (or known!) setups to begin with.


I might be off the deep end, but isn't this what
Documentation/feature-removal-schedule.txt is for?


Documentation/feature-removal-schedule.txt is for asking/discussing whether 
or not features should be removed? No, I don't think so. It seems to be a 
schedule of when to remove features.


Rene.


--
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: ide=reverse do we still need this?

[Rene Herman]

On 13-02-08 13:06, Rene Herman wrote:

On 13-02-08 05:44, Greg KH wrote:


While details escape me somewhat again at the monment, a few months ago
I was playing around with a PCI Promise IDE controller and needed
ide=reverse to save me from having to switch disks around to still have
a bootable system.

Or some such. Not too clear anymore, but I remember it saved the day.


You couldn't just change the boot disk in grub?

Or use an initramfs and /dev/disk/by-id/ to keep any future moves stable?


No. The thing is that you need these kinds of hacks while messing with 
old systems, building and stripping them, often in recovery type of 
situations.


As said (same as the other person I saw reacting) details of what was 
most decidedly needed last time around escape me at the moment, but 
ide=reverse is the kind of hack that saves one hours of unscrewing 
computer cases and switching disks around while building stuff, making 
quick tests, doing recovery...


If it must go for the greater architectural good, so be it, but it's the 
type of thing that's used specifically in the situations where you don't 
have stable, well arranged (or known!) setups to begin with.


Allow me to add that the demise of drivers/ide itself is an argument for 
just shooting the thing if it helps clean up the API. Next year when I'm 
messing with that Promise controller again, the machine might very well be 
running a kernel using PATA instead of IDE anyway...


Rene.

--
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] feature-removal: add documentation for exported symbols going away

[Rene Herman]

On 13-02-08 23:22, Harvey Harrison wrote:


+---
+
+What:  io_delay_type
+Where: arch/x86/kernel/io_delay.c
+When:  2.6.28
+Why:   No in tree users


The entirety of io_delay.c should be gone long before .28. It's a short term 
thing till the port 0x80 problems have been dealt with.


Rene.
--
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: Feature Removals for 2.6.25

[Rene Herman]

On 15-02-08 00:20, David Newall wrote:


Arjan van de Ven wrote:

Bill Davidsen wrote:

Note that because the hardware is old, it's highly likely that most
of it will be retired before that sk98lin driver needs a change. I
can't see anyone using sk98lin on a new system, so it would be less
contentious to let the hardware (or users) die of natural causes if
you can.


the problem is that the new one DOES NOT GET FIXED.
THAT is a huge problem; it means we have a buggy driver...


If the old one works and the new one is buggy, it begs the question of
why anybody bothered writing a new one in the first place.  If it ain't
broke, don't fix it, might have been good advice to follow.


Not generally. A usual scenario is the new driver working on newer hardware 
versions than the old one supports but not necessarily on all the old ones 
the previous driver supported if only due to to availability of the older 
hardware for testing.


Rene.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -mm] sb16: Shut up uninitialized var build warning

[Rene Herman]

On 09/20/2007 07:52 PM, Denys Vlasenko wrote:


On Sunday 02 September 2007 23:06, Rene Herman wrote:



Blah. Your message has:

Content-Type: TEXT/PLAIN; charset=iso-2022-jp

This apparently is caused by a combination of GCC using groovy UTF tickmarks 
in its error messages when in a UTF locale and alpine believing it to be a 
great idea to automatically try for the simplest character set it can 
encode the content in. No idea why that means that iso-2022-jp is picked, 
but it is.


While I could actually read the message this time you should see what 
iso-2022-jp does to my font. It's scary. Best solution as far as I'm 
concerned is slap a few GCC developers (not that it wil help, but it'll 
certainly feel good) and then teach alpine to go for UTF-8 directly if 
US-ASCII won't do.


rotfl.

Kindly give me permission to convert your email into gcc bugreport
and/or to forward it to gcc mailing list.


Blessings be upon thou, oh courageous one...

Rene.

-
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: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage

[Rene Herman]

On 10/07/2007 06:12 PM, Ingo Molnar wrote:


* Oleg Verych [EMAIL PROTECTED] wrote:



Coloring isn't useful. If it was, it would be implemented ~16 years
ago.


Congratulations, this is the most stupid argument i've ever read on 
lkml.


Ay. World is finished. Everyone can go home and watch Friends reruns now.

But well, there actually have been worse arguments given that VGA console is 
getting less and less important. I recently did a perusal of alternative 
distributions and didn't find a single one that didn't default to having a 
splash screen hide the kernel during boot (and if I'm not mistaken, only one 
of them provided me with the option during installation to not boot into X 
immediately afterwards).


Sure, that in itself needn't necesarily be of concern to anyone who, err, is 
not concerned but any such colouring feature appearing when there's only a 
smathering of people left that still cares about the VGA console in the 
first place really isn't all _that_ far out as an argument...


Rene.
-
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: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage

[Rene Herman]

On 10/07/2007 08:58 PM, Jan Engelhardt wrote:


On Oct 7 2007 20:47, Rene Herman wrote:



Coloring isn't useful. If it was, it would be implemented ~16 years
ago.

Congratulations, this is the most stupid argument i've ever read on lkml.

Ay. World is finished. Everyone can go home and watch Friends reruns now.

But well, there actually have been worse arguments given that VGA console is
getting less and less important.
[...]
Sure, that in itself needn't necesarily be of concern to anyone who,
err, is not concerned but any such colouring feature appearing when
there's only a smathering of people left that still cares about the VGA
console in the first place really isn't all _that_ far out as an
argument...


In case you have not noticed, the coloring also applies to FB. As far as
I can oversee, it's only missing for serial and PROMs.


Must say I did concentrate on VGA, but the [...] bit in the quote above was 
about how everything I encountered put up a bootsplash hiding _everything_ 
and about booting into X immediately, not about FB...


I saw you remark on FB console in a reply to Alan just now and I quite agree 
with you. The (current) FB console is slow and I'll add dumb myself. When 
you have a 1280x1024 screen available, you get to do cool things like put up 
nice little windows and exclamation mark icons on errors, not just pretend 
you're really 132x50 (or whatever).


Alan's sketched more generic markup/unification would be The Way Forward it 
seems. Given that TWF is mostly defined as That Which Is Not (and how it 
seems to have a tendency to defend that status vigorously) telling me/us to 
shelve that objection for 10 years might be okay -- but generally I'm having 
a fairly hard time getting excited about printk colourizing.


Rene.

-
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: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage

[Rene Herman]

On 10/07/2007 09:13 PM, Willy Tarreau wrote:


On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote:


But well, there actually have been worse arguments given that VGA console 
is getting less and less important. I recently did a perusal of alternative 
distributions and didn't find a single one that didn't default to having a 
splash screen hide the kernel during boot (and if I'm not mistaken, only 
one of them provided me with the option during installation to not boot 
into X immediately afterwards).


I don't recall having seen any splash screen on Slackware.


Indeed, but that's the distribution I use and considered switching away 
from. Just my luck eh? :-\



There are two distinct populations :
  - those who are afraid of boot messages and prefer splash screens.
Those people are most common users, grown in non-IT environments. They
are happy to see a big logo on their BIOS to hide important boot errors,
and they are the ones who would never have imagined that pressing Escape
during the boot of windows 3.1/95 provided them with the full text
messages. Basically, they want to ensure they will never have to worry
about things they don't understand.


Nor want to understand, often.


  - those who are troubleshooting their system in the early stages (kernel,
filesystems, network, services, ...). These ones *need* boot messages.
And there, depending on the hardware, sometimes the FB is better because
it shows larger lines, sometimes it's worse because the scrollback is
limited by too low memory.

I personally fit in the second category. And I'm sure most people on this
list do.


As do I ofcourse. An operating system kernel development list might provide 
for a fairly non-average balanced population of am / am not interested in 
the inner workings of computers. Given that most everyone these days uses a 
computer, it's still a really small percentage though -- and as evidenced by 
the bootsplash thing, even of Linux users (and I've in fact heard real-life 
people say they disliked the noisy Linux bootup due to all those errors).



I would be miserably sad if I couldn't get my boot messages anymore. It
already irritates me a lot to loose the ones displayed before switching
to frame-buffer when a hang happens just afterwards...


Oh quite. I use VGA console myself. But not being able to get to the bootup 
messages anymore even for people who do care is not the issue. It's about 
finding it a bit hard to get excited about colourization when the obvious 
way forward is so much more graphically oriented.


As also commented in another reply just now, ways forward also tend to have 
their problems but this kind of innovation takes me back to the time when 
our favorite bulletins board adopted ANSI colours. Today, that seems just a 
tad pathetic...


Again, it might not hurt any either, but sheesh.

Rene.
-
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: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage

[Rene Herman]

On 10/07/2007 09:56 PM, Jan Engelhardt wrote:

Some is good, as long as it is not excessive. While I could imagine that 
Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, 
this is not what serious people would do.


[1] http://tinyurl.com/yr9zgq
[2] http://tinyurl.com/234ba3


Given this discussion, I find it really appropriate that you are posting 
_graphics_ of your text screens :-)


Rene.

-
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: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage

[Rene Herman]

On 10/07/2007 10:04 PM, Jan Engelhardt wrote:


On Oct 7 2007 22:00, Rene Herman wrote:

On 10/07/2007 09:56 PM, Jan Engelhardt wrote:


Some is good, as long as it is not excessive. While I could imagine that
Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this
is not what serious people would do.

[1] http://tinyurl.com/yr9zgq
[2] http://tinyurl.com/234ba3

Given this discussion, I find it really appropriate that you are posting
_graphics_ of your text screens :-)


I can give you a VCSA file (as produced by /dev/vcsa1) if you like,
complete with VCSA reader.


No, the PNGs will do thanks, it was obviuously a bit of a cheap shot. Still, 
it _is_ somewhat of a comment on what's expected these days.


Rene

-
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: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage

[Rene Herman]

On 10/08/2007 12:40 AM, Alistair John Strachan wrote:

Splash screens are clearly cosmetic, and it's kind of shameful (imo) that 
important messages explaining real problems are obscured from view by 
functionless splash screens.


They're not functionless. You (and I) might not care for the function, but 
their function is providing a slick bootup. That's why so many if not 
basically all distributions of recent origin use them. Go ask Ubuntu for 
example.


Personally, I think muddying the vga colour argument with splash screen stuff 
is bogus, they're very functionally separable ideas. A coloured oops seems to 
be a good way of telling novice users what information is relevant to their 
bug report.


But when they're hidden by a splash screen, you don't see them any better 
when they're red than when they're white. Splash screens were not mentioned 
as any sort of alternative, their prevalence was mentioned as indication 
that VGA console is only ever getting less important.


I find Alan's suggestion to provide the functionality the same way you'd 
provide for translated kernel messages (seeing as how there also are people 
that want those) much more sensible.


Rene.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -mm] sb16: Shut up uninitialized var build warning

[Rene Herman]

On 09/02/2007 10:15 PM, Satyam Sharma wrote:


sound/isa/sb16/sb16.c: In function ‘snd_sb16_isa_probe’:


Blah. Your message has:

Content-Type: TEXT/PLAIN; charset=iso-2022-jp

This apparently is caused by a combination of GCC using groovy UTF tickmarks 
in its error messages when in a UTF locale and alpine believing it to be a 
great idea to automatically try for the simplest character set it can 
encode the content in. No idea why that means that iso-2022-jp is picked, 
but it is.


While I could actually read the message this time you should see what 
iso-2022-jp does to my font. It's scary. Best solution as far as I'm 
concerned is slap a few GCC developers (not that it wil help, but it'll 
certainly feel good) and then teach alpine to go for UTF-8 directly if 
US-ASCII won't do.


As to the content of this patch -- I'd almost say it's better to live with 
the warning than with that unitialized_var() thing. That ARRAY_SIZE is very 
much a compile time constant, so exactly how dumb must GCC get before we get 
to say to here and no further?



--- linux-2.6.23-rc4-mm1/sound/isa/sb/sb16.c~fix2007-09-02 
21:41:51.0 +0530
+++ linux-2.6.23-rc4-mm1/sound/isa/sb/sb16.c2007-09-02 21:42:56.0 
+0530
@@ -556,7 +556,6 @@ static int __devinit snd_sb16_isa_match(
 
 static int __devinit snd_sb16_isa_probe(struct device *pdev, unsigned int dev)

 {
-   int err;
static int possible_irqs[] = {5, 9, 10, 7, -1};
static int possible_dmas8[] = {1, 3, 0, -1};
static int possible_dmas16[] = {5, 6, 7, -1};
@@ -585,6 +584,8 @@ static int __devinit snd_sb16_isa_probe(
else {
static int possible_ports[] = {0x220, 0x240, 0x260, 0x280};
int i;
+   int uninitialized_var(err);
+
for (i = 0; i  ARRAY_SIZE(possible_ports); i++) {
port[dev] = possible_ports[i];
err = snd_sb16_isa_probe1(dev, pdev);


Rene.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -mm] es18xx: Shut up uninitialized var build warning

[Rene Herman]

On 09/02/2007 10:21 PM, Satyam Sharma wrote:


sound/isa/es18xx.c: In function ‘snd_es18xx_isa_probe’:
sound/isa/es18xx.c:2251: warning: ‘err’ may be used uninitialized in this 
function

gcc is a sad, sad compiler. This warning is bogus so let's shut it up.


Same situation, same comment (and same charset :-( ) as the sb16 one.

Rene.
-
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: sata scsi suggestion for make menuconfig

[Rene Herman]

On 09/10/2007 08:38 AM, Stefan Richter wrote:


Nevertheless we should try to arrange the menus in a way that makes
sense to as many people as possible.  The difficulty is, different
environments call for different menu layouts, as your previous example
of SATA DVD-only boxes demonstrates.

However, liberal usage of 'select' is not the ultimate solution to
create menus that work for more people.  Just one problem with select is
that it works behind the back of the people configuring kernels (unless
they use an UI with debug options turned on) --- they have less control,
they are less informed.  ATA already 'select's SCSI.  What do we gain
from hiding the fact that Linux' SCSI option is not just for those
50-wire ribbons (which people still think SCSI stands for) but is a very
central Linux subsystem for even more than what complies to the SCSI
family of standards?

'select' should really be limited to switch on small library-like code
without further dependencies or requirements.  SCSI, together with its
upper layer options, is not of this kind of library.

We should think about order and grouping of prompts and the labels of
prompts (there were already suggestions in this discussion) before we
resort to 'select' --- or even worse, select options unconditionally
which are not always necessary to be enabled.

A pro pos grouping of options --- consider how options for another
central subsystem are laid out:

Networking
Networking options
...
TCP/IP networking
...
...

Device Drivers
...
Network device support
...
Ethernet (10 or 100MBit)
...
...

This also happens to reflect the layout of sources in directories, and
the current SCSI menu layout is close to source layout too --- but it
doesn't have to be that way.


If someone's keen on really restructuring these things -- in this analogy:

Storage
Storage Options
...
Disk
Optical
...
...

Device Drivers
...
Storage Support
...
IDE
PATA
SATA
SCSI
USB
FW
...
...

(sound is an example where both in the menus and the tree everything is kept 
under one top-level sound/ directory, not sound/ and drivers/sound/ as for 
networking -- opinions may vary which one's better I guess).


This is just config menus -- on a source code level, it would also make 
sense at least at some point to introduce storage/ alongside net/ and 
sound/ and move things around I guess.


Rene.

-
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: [-mm patch] unexport sys_{open,read}

[Rene Herman]

On 09/11/2007 12:18 AM, Adrian Bunk wrote:


On Mon, Sep 10, 2007 at 01:17:59PM -0700, Andrew Morton wrote:



There is no benefit in making some rigid set of rules.


Is is considered beneficial to provide API stability for external 
modules or not?


If I may...

Yes, it is. Just not at any significant cost and Andrew is saying that he 
considers the _UNUSED() thing not significant.


Rene.
-
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: [-mm patch] unexport sys_{open,read}

[Rene Herman]

On 09/11/2007 12:41 AM, Adrian Bunk wrote:


On Tue, Sep 11, 2007 at 12:15:56AM +0200, Rene Herman wrote:

On 09/11/2007 12:18 AM, Adrian Bunk wrote:


On Mon, Sep 10, 2007 at 01:17:59PM -0700, Andrew Morton wrote:

There is no benefit in making some rigid set of rules.
Is is considered beneficial to provide API stability for external modules 
or not?

If I may...

Yes, it is. Just not at any significant cost and Andrew is saying that he 
considers the _UNUSED() thing not significant.


But there is no API stability for external modules this way.


I agree that doing things only half is semi-regularly worse than doing them 
not at all, and this specific case might be the worst example of all, as I 
read that using sys_open/read is actively harmful, so, well...


I read the thread since I tend to keep lots of external crap around. Not in 
any way that would mean I'd have any grounds for complaining about anything; 
mostly just driver stuff in various states of completeness that I never seem 
to get around to cleaning up enough to submit to anyone.


But as such, I can comment on the fact that I'm much more likely to notice 
the warning than I am to notice a thread on LKML, say. How much more likely 
I'd be to then also actually do anything about it before it just breaks 
anyway is another matter, but again, well...


It simply doesn't make sense to give the few sys_open() abusers even 
more grace period while changes to the IRQ API affecting nearly everyone 
are allowed without any requirements of ensuring API stability.


I'm not a fan of API stability for external modules, but if API 
stability was considered important it should be done consequently and 
not only for some patches that have the bad fate of having to go through 
Andrew to Linus.


In this case I believe it makes sense to just rip it out, but generally it 
doesn't need to be such a fully robotic yes/no decision, I'd say.


Rene.
-
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: time_after - what on earth???

[Rene Herman]

On 09/12/2007 12:05 AM, Adrian McMenamin wrote:


OK, why does this line occasionally return true:

if ((maple_dev-interval  0)  (jiffies maple_dev-when))

while this one never does (no other changes made):

if  ((maple_dev-interval  0)  (time_after(jiffies, maple_dev-when)))


Is maple_dev-when an unsigned long?

Rene.
-
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: time_after - what on earth???

[Rene Herman]

On 09/12/2007 12:15 AM, Adrian McMenamin wrote:


On 11/09/2007, Rene Herman [EMAIL PROTECTED] wrote:

On 09/12/2007 12:05 AM, Adrian McMenamin wrote:


OK, why does this line occasionally return true:

  if ((maple_dev-interval  0)  (jiffies maple_dev-when))

while this one never does (no other changes made):

if  ((maple_dev-interval  0)  (time_after(jiffies, maple_dev-when)))

Is maple_dev-when an unsigned long?


Yes. Does that make a difference?


If it had been a signed type, it could've wrapped to something you didn't 
expect, explaining the difference at least...


With an unsigned long, the only diference should be that time_after() deals 
with jiffie wrapping which I assume is not an actual problem here. I'll 
retreat into the shades again... ;-(


Rene.

-
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: time_after - what on earth???

[Rene Herman]

On 09/12/2007 01:09 AM, Björn Steinbrink wrote:

On 2007.09.12 00:19:09 +0200, Rene Herman wrote:

On 09/12/2007 12:15 AM, Adrian McMenamin wrote:


On 11/09/2007, Rene Herman [EMAIL PROTECTED] wrote:

On 09/12/2007 12:05 AM, Adrian McMenamin wrote:


OK, why does this line occasionally return true:


What exactly is occassionally?  Does it happen more than once per
boot? If not, and it happens after a certain time after booting, it
might be wrapping of the jiffie counter (see below).


  if ((maple_dev-interval  0)  (jiffies maple_dev-when))

while this one never does (no other changes made):

if  ((maple_dev-interval  0)  (time_after(jiffies, 
maple_dev-when)))

Is maple_dev-when an unsigned long?


Yes. Does that make a difference?
If it had been a signed type, it could've wrapped to something you didn't 
expect, explaining the difference at least...


With an unsigned long, the only diference should be that time_after() deals 
with jiffie wrapping which I assume is not an actual problem here. I'll 
retreat into the shades again... ;-(


If occasionally is limited to once per boot, it might be jiffie
wrapping. IIRC jiffies are initialized so that they wrap after about 5
minutes of uptime to reveal such bugs without forcing you to wait for
ages just to have the counter wrap for the first time.


Yes, but if jiifie wrapping was the problem, I'd expect the contrary 
behaviour with the time_after() one hitting while the  one does not.


Rene.
-
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: [RFH] Partition table recovery

[Rene Herman]

On 07/20/2007 02:22 PM, Al Boldi wrote:


Oh, gpart is great, but if we had a backup copy of the partition table on
every partition location on disk, then this backup copy could easily be
reused to reconstruct the original partition table without further 
searching.


As long as you don't reboot you have a backup copy in kernel. Admittedly 
not in a very nice format, but /sys/block/disk/part/start and size have 
saved my butt a few times...


Rene.
-
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: [RFH] Partition table recovery

[Rene Herman]

On 07/20/2007 06:06 PM, Theodore Tso wrote:


It wouldn't be that hard to put a backup partition table at the beginning
of an ext2/3 filesystem.  No one is currently using the space between
offset 512 and 1023 bytes, and it would be an easy place to stash a
backup copy of the partition table.  We wouldn't be able to use the MBR
format, since information about extended partitions are stored scattered
across the disk.


I was looking into this, but I'm afraid I believe it's not a very good idea.


So for the sake of argument, I'll propose the following partition
backup, starting at offset 512 and going for 512 bytes to byte #1023:

offset 
from 512  Description

---   ---
0..7  Signature ASCII: PARTBAK1
8..9  Part-type: 1=MBR


Not sure what you mean with this type field. You were suggesting to only 
backup Plain Ol' Partition tables anyway weren't you?



10# of heads
11# sectors


This is a problem. Today the CHS fields in the partition entries don't mean 
much of anything anymore and Linux happily ignores them but DOS and (hence) 
Windows 9x do not. From time to time I still have the Windows 98 install 
that's sitting in a corner of my disk throw a fit just by having set the 
BIOS from LBA to Large (meaning the geometry the BIOS pretends the disk has 
changes) for example. Old DOS installs that I keep around for the purpose of 
hardware testing with the originally supplied drivers make for even more of 
a don't touch, don't touch! thing -- various version of DOS throw fits for 
various reasons.


As such, really the only functional thing to do is backup _whatever_ is 
there in the CHS fields in the entries currently and unfortunately this can 
vary between entries, and certainly between runs of whatever program creates 
them. For example, the user may have adjusted the layout in the BIOS or some 
or all partitions may have been created while the disk was in a different 
machine all together. That is to say, really no attempt should be made at 
being smart about the CHS values -- a backup should just store the actual 
(16-byte) partition table entry.



12# of partitions in the backup
13..15Reserved (must be zero)
16..31first part entry
...
496..511 31st partition entry


And this is the biggest problem. IDE for example allows 63 partitions and 
while in practice not many people will actually also have used that many, 31 
isn't hugely roomy either especially due to the way extended partitions are 
kept.


An extended partition is a partition with type (0x05 || 0x0F || 0x85) the 
first sector of which contains another partition table. That second-level 
partition table generally consists of two entries; the first for the logical 
(actual) partition and the second being yet another extended partition, 
where walking the list gets you all.


However, there can be more than just 1 extended partition on a disk and this 
isn't (or wasn't...) in fact uncommon. Windows 9x at least used to create 
multiple partitions as 1 primary and the rest (even if just 1 as well) as 
logicals inside one 0x05/0x0F extended. When you then installed Linux onto 
the same disk, needed more than the 3 MBR entries left, and wanted to make 
sure that Windows wouldn't trip over any non-fat entries in the list of 
extended partitions (which it did) you'd create 1 0x85 Linux only extended 
 in the MBR that Windows just ignores -- not a problem since it couldn't 
read any of the filesystems on them anyway.


This already means you need to keep more information that just the logicals 
(the actual partitions) since you can't reliably restore the tables from a 
list of them alone.


Moveover, the generally consists of two entries above isn't guaranteed 
either. The second-level table _can_ contain more than 1 logical. Linux 
never minded much of anything and back when I was experimenting with more 
operating systems (on one disk) they did -- I used to mostly create my 
partition tables with Norton Diskedit at the time...


A bullet-proof backup then has to really store these actual second-level 
tables verbatim again as you can't assume too much about them meaning you're 
going to be storing a complete 4-entry table for every logical which 
ofcourse eats space in the available 512 bytes / 31 entries _way_ too fast.


Moreover once more -- why stop at normal logicals? I for example have a 
MINIX 2 partition sitting on this disk and it uses a subpartitioning scheme 
through the same DOS-style second-level partition-table setup. First entry 
in the second-level table is generally used for / and third for /usr meaning 
two additional partitions. And if two aren't bad enough, from time to time 
(when after buying a new disk my ogg vorbis collection hasn't yet grown to 
fill it again yet) I keep a FreeBSD install around which means 6 or so 
additional slices.


Ignoring those alien partitions is sort of okay, but as said, with only 512 
bytes to spare, this is all inevitable going to be a sorta 

Re: [RFH] Partition table recovery

[Rene Herman]

On 07/22/2007 03:11 AM, Theodore Tso wrote:


This is a problem. Today the CHS fields in the partition entries don't
mean much of anything anymore and Linux happily ignores them but DOS
and (hence) Windows 9x do not. From time to time I still have the
Windows 98 install that's sitting in a corner of my disk throw a fit
just by having set the BIOS from LBA to Large (meaning the geometry the
BIOS pretends the disk has changes) for example. Old DOS installs that
I keep around for the purpose of hardware testing with the originally
supplied drivers make for even more of a don't touch, don't touch!
thing -- various version of DOS throw fits for various reasons.


This is true, but that's due to the fundamentally broken nature of CHS.
You need them to boot, and that's about it.  I will say up front that I
don't particularly care about legacy operating system such as DOS,
Windows 98, or Minix 3.  So the idea of simply having the number of heads
and sectors in the partition header is that we can reconstruct CHS fields
such that it is likely with modern hardware you will get it right.


Well, I still don't believe this all to be a great idea but it was sort of 
fun so the attached does largely what you want -- build a list of all data 
partitions.


The heads/sectors fields it for now just gets from the HDIO_GETGEO call. A 
better source would be guessing the values from the partition table itself 
but that _also_ doesn't make too much sense. If you're reconstructing a 
sanitized version of the table anyway, it makes better sense to reconstruct 
it with the values HDIO_GETGEO returns at restoration time.


I kept your suggested format, but in fact, the 64-bit start value seems 
not very useful if we're getting the value from a 32-bit field in the old 
partition tables anyway. With that shrunk down to 32-bit again, there would 
be enough room for the complete partition table entry...



For ancient systems that do all sorts of weird things such as ECHS,
etc., yeah, you're pretty much doomed, and the bigger danger comes
from futzing with BIOS settings, et. al.  But it's 2007, gosh darn it!
Here's a quarter, kid, buy yourself a real computer.  :-)


Thanks, but real computers won't host my ISA cards...


Yes, I'm very aware of the extended partitioning scheme mess.  What I
was proposing to back up here is only the real partitions, not the
fake extended partitions.  The idea is to store *just* enough
information so that a partition table manager can recover the
partition tables in such a way that the original filesystem
information can be recovered.


This should do I guess. It enters all data partitions into the list, in the 
order in which they are encountered and sets a flag to signify that a 
partition was a logical rather than primary. Another option would be to just 
reserve the first 4 entries for the primaries and the rest for the logicals 
but this saves entries if there are fewer than 4 primaries and was in fact 
easier...


The program enters partitions in what should be the same order as Linux 
itself does. Primaries from slot 0 to 3 as normal (but not backed up to 
entry 0 to 3 as said -- the LOGICAL flag indentifies them), extended 
partitions in the MBR in the order as encountered, with the logicals in the 
second-level table as encountered, and following only the first extented in 
the second-level table.


Made it into a generic C program -- didn't look at e2fsprogs sources yet.

Need to be off now and haven't yet stared at this as long as I'd like so 
don't slap me if I've left a few bugs in (although it seems to work nicely). 
The program dumps the backup sector to stdout -- it's ofcourse easy to 
change it to print the entries out so they're easy to compare against, say, 
fdisk -l -us.


Oh, and once you've looked at it, please throw it away. As said, I still 
don't think it's a great idea ;-)


Rene.

/*
 * Public Domain 2007, Rene Herman
 *
 * gcc -W -Wall -DTEST -D_LARGEFILE64_SOURCE -o backup backup.c
 *
 */

#include stdlib.h

enum {
DOS_EXTENDED   = 0x05,
WIN98_EXTENDED = 0x0f,
LINUX_EXTENDED = 0x85,
};

struct partition {
unsigned char boot_ind;
unsigned char __1[3];
unsigned char sys_ind;
unsigned char __2[3];
unsigned int start;
unsigned int size;
} __attribute__((packed));

struct entry {
unsigned char flags;
unsigned char type;
unsigned short __1;
unsigned long long start;
unsigned int size;
} __attribute__((packed));

enum {
ENTRY_FLAG_LOGICAL  = 0x01,
ENTRY_FLAG_BOOTABLE = 0x80,
};

struct backup {
unsigned char signature[8];
unsigned short type;
unsigned char heads;
unsigned char sectors;
unsigned char count;
unsigned char __1[3];
struct entry table[31];
} __attribute__((packed));

#define BACKUP_SIGNATURE PARTBAK1

enum {
BACKUP_TYPE_MBR = 1,
};

struct backup backup = {
.signature

Re: [RFH] Partition table recovery

[Rene Herman]

On 07/22/2007 06:28 PM, Theodore Tso wrote:

[ Al -- don't drop CCs please ]


Well, let's think about this a bit.  What are the requirements?

1) The partition manager should be able explicitly request that a new
backup of the partition tables be stashed in each filesystem that has
room for such a backup.  That way, when the user affirmatively makes a
partition table change, it can get backed up in all of the right
places automatically.


D-Bus? ;-)


2) The fsck program should *only* stash a backup of the partition
table if there currently isn't one in the filesystem.  It may be that
the partition table has been corrupted, and so merely doing an fsck
should not transfer a current copy of the partition table to the
filesystem-secpfic backup area.  It could be that the partition table
was only partially recovered, and we don't want to overwrite the
previously existing backups except on an explicit request from the
system administrator.

3) The mkfs program should automatically create a backup of the
current partition table layout.  That way we get a backup in the newly
created filesystem as soon as it is created.


On an integrated system like this, do you consider it acceptable to only do 
the MS-DOS partitions and not the other types that may be present _inside_ 
those partitions? (MINIX subpartitions, BSD slices, ...). I believe those 
should really also be done, but this would require keeping more information 
again.



4) The exact location of the backup may vary from filesystem to
filesystem.  For ext2/3/4, bytes 512-1023 are always unused, and don't
interfere with the boot sector at bytes 0-511, so that's the obvious
location.  Other filesystems may have that location in use, and some
other location might be a better place to store it.  Ideally it will
be a well-known location, that isn't dependent on finding an inode
table, or some such, but that may not be possible for all filesystems.

OK, so how about this as a solution that meets the above requirements?

/sbin/partbackup device [fspart]

Will scan device (i.e., /dev/hda, /dev/sdb, etc.) and create
a 512 byte partition backup, using the format I've previously
described.  If fspart is specified on the command line, it
will use the blkid library to determine the filesystem type of
fspart, and then attempt to execute
/dev/partbackupfs.fstype to write the partition backup to
fspart.  If fspart is '-', then it will write the 512 byte
partition table to stdout.  If fspart is not specified on
the command line, /sbin/partbackup will iterate over all
partitions in device, use the blkid library to attempt to
	determine the correct filesystem type, and then execute 
	/sbin/partbackupfs.fstype if such a backup program exists.


I've cleaned up what I posted yesterday a bit and made it into the type of 
standalone-by-design program you suggest here (the version from yesterday 
required a -DTEST to be so). Not with the blkid bits though. Just dumps the 
sector to stdout (and a textual version to stderr if compiled with -DDEBUG).


I (very) briefly looked at blkid but unless I'm mistaken blkid needs device 
names? The documentation seems to be missing. When scanning the device for 
the partition table, we've built a list of partitions with offsets into the 
device and it would be nice if we could hand the fd and the offset off to 
something directly. If the program has to construct device names itself 
there's another truckload of pitfalls right there.


It wouldn't be hard to log minors as such, but you'd also need to be very 
sure you'd always do this in the same order as the kernel so that what I 
consider to be /dev/sda2 is the same the kernel considers it to be. This 
is again rather fragile.


It might in fact make sense to just ask the kernel for the partitions on a 
device and not bother with scanning anything ourselves. Ie, just walk sysfs. 
Would you agree? This siginificantly reduces the risk of things getting out 
of sync, both scanning order and implementation.


The kernel doesn't currently store/export everything you'd want to store in 
a backup (as far as I'm aware, that is) but that could conceivably change. 
It would make things significantly less fragile.


Rene.
/*
 * Public Domain 2007, Rene Herman
 */

#define _LARGEFILE64_SOURCE

#include stdlib.h
#include stdio.h
#include stdint.h
#include string.h

#include sys/types.h
#include sys/stat.h
#include sys/ioctl.h
#include unistd.h
#include fcntl.h

enum {
DOS_EXTENDED   = 0x05,
WIN98_EXTENDED = 0x0f,
LINUX_EXTENDED = 0x85,
};

struct partition {
uint8_t boot_ind;
uint8_t head;
uint8_t sector;
uint8_t cyl;
uint8_t sys_ind;
uint8_t end_head;
uint8_t end_sector;
uint8_t end_cyl;
uint32_t start;
uint32_t size;
} __attribute__((packed));

struct entry {
uint8_t flags;
uint8_t type

Re: [RFH] Partition table recovery

[Rene Herman]

On 07/23/2007 10:41 AM, Jan-Benedict Glaw wrote:


As multibyte on-disk variables, these will need LE/BE conversion.


Indeed, thanks -- has been updated in the version that is attached.

Also fixes a bug that snuck in (failed to add offset to entry-start).


struct entry {
uint8_t flags;
uint8_t type;
uint16_t __1;
uint64_t start;
uint32_t size;


Dito.


This can stay for now. The partition table backup would indeed need some 
defined byte-order but it might be whatever order the filesystem it's 
backed up onto uses. Since it's not directly written to any filesystem for 
now, host order will do currently.



Looks like a useful program, but you'd definively fix the LE/BE issues.
If you do that, it'll be able to even run on BE machines, too.


I might disagree with the usefulness. I believe that preferably a backup 
should be made with help from the kernel (if only by walking sysfs) to avoid 
things getting out of sync between kernel and backup program.


(this program largely does the same as the kernel does but even now there's 
already a difference in so far that I didn't bother to de-garbage the 3rd 
and 4th entries in the second level extendeds).


Rene.

/*
 * Public Domain 2007, Rene Herman
 */

#define _LARGEFILE64_SOURCE

#include stdlib.h
#include stdio.h
#include stdint.h
#include string.h

#include sys/types.h
#include sys/stat.h
#include sys/ioctl.h
#include unistd.h
#include fcntl.h

#include endian.h
#include byteswap.h

static inline uint32_t le_32(uint32_t n)
{
#ifdef __LITTLE_ENDIAN
return n;
#else
return bswap_32(n);
#endif
}

enum {
DOS_EXTENDED   = 0x05,
WIN98_EXTENDED = 0x0f,
LINUX_EXTENDED = 0x85,
};

struct partition {
uint8_t boot_ind;
uint8_t head;
uint8_t sector;
uint8_t cyl;
uint8_t sys_ind;
uint8_t end_head;
uint8_t end_sector;
uint8_t end_cyl;
uint32_t start;
uint32_t size;
} __attribute__((packed));

struct entry {
uint8_t flags;
uint8_t type;
uint16_t __1;
uint64_t start;
uint32_t size;
} __attribute__((packed));

enum {
ENTRY_FLAG_PRIMARY  = 0x01,
ENTRY_FLAG_BOOTABLE = 0x80,
};

struct backup {
uint8_t signature[8];
uint16_t type;
uint8_t heads;
uint8_t sectors;
uint8_t count;
uint8_t __1[3];
struct entry table[31];
} __attribute__((packed));

#define BACKUP_SIGNATURE PARTBAK1

enum {
BACKUP_TYPE_MBR = 1,
};

struct backup backup = {
.signature = BACKUP_SIGNATURE,
.type  = BACKUP_TYPE_MBR,
};

#define ARRAY_SIZE(arr) (sizeof arr / sizeof arr[0])

int is_extended(struct partition *partition)
{
int ret = 0;

switch (partition-sys_ind) {
case DOS_EXTENDED:
case WIN98_EXTENDED:
case LINUX_EXTENDED:
ret = 1;
}
return ret;
}

unsigned char *get_sector(int fd, uint64_t n)
{
unsigned char *sector;

if (lseek64(fd, n  9, SEEK_SET)  0) {
perror(lseek64);
return NULL;
}
sector = malloc(512);
if (!sector) {
fprintf(stderr, malloc: out of memory\n);
return NULL;
}
if (read(fd, sector, 512) != 512) {
perror(read);
free(sector);
return NULL;
}
return sector;
}

void put_sector(unsigned char *sector)
{
free(sector);
}

#define TABLE_OFFSET (512 - 2 - 4 * sizeof(struct partition))

inline struct partition *table(unsigned char *sector)
{
return (struct partition *)(sector + TABLE_OFFSET);
}

int do_sector(int fd, uint32_t offset, uint32_t start)
{
unsigned char *sector;
struct partition *cur;
struct partition *ext = NULL;
int ret = 0;

sector = get_sector(fd, offset + start);
if (!sector)
return -1;

if (sector[510] != 0x55 || sector[511] != 0xaa) {
ret = -1;
goto out;
}
for (cur = table(sector); cur  table(sector) + 4; cur++) {
struct entry *entry;

if (!cur-size)
continue;

cur-end_head += 1;
if (backup.heads  cur-end_head)
backup.heads = cur-end_head;

cur-end_sector = 0x3f;
if (backup.sectors  cur-end_sector) 
backup.sectors = cur-end_sector;

if (is_extended(cur)) {
if (!offset) {
ret = do_sector(fd, le_32(cur-start), 0);
if (ret  0)
goto out;
} else if (!ext)
ext = cur;
continue

Re: SCSI vs SATA

[Rene Herman]

On 07/23/2007 12:52 PM, BuraphaLinux Server wrote:


#!  /bin/bash
drive=sda
vendor=$(/sys/block/${drive}/device/vendor)
if [[ ${vendor} = ATA  ]]
then
 printf SATA\n
else
 printf SCSI\n
fi
exit 0


This is probably not a useful comment and a reasonable script in your local 
setting but still thought I'd point out that these days most anything is 
sda, so if !SATA it can generally also be USB, or FW, or ...


Rene.

-
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: [RFH] Partition table recovery

[Rene Herman]

On 07/23/2007 12:54 PM, Rene Herman wrote:


static inline uint32_t le_32(uint32_t n)
{
#ifdef __LITTLE_ENDIAN
return n;
#else
return bswap_32(n);
#endif
}


#if __BYTE_ORDER == __LITTLE_ENDIAN, that is. sigh.

Rene.
-
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: [RFH] Partition table recovery

[Rene Herman]

On 07/23/2007 03:15 PM, Jan-Benedict Glaw wrote:


static inline uint32_t le_32(uint32_t n)
{
#ifdef __LITTLE_ENDIAN
return n;
#else
return bswap_32(n);
#endif
}

#if __BYTE_ORDER == __LITTLE_ENDIAN, that is. sigh.


Don't forget PDP11 byteorder :-)


How could I? It cracks me up every time...

Rene.
-
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/7] lguest: documentation pt I: Preparation

[Rene Herman]

On 07/24/2007 03:18 AM, Linus Torvalds wrote:


PS. Nothing rhymes with Ballalaba.


There once was a woman from Ballalaba
who hid kernel bugs in her djellabah.
 When her husband found out,
  he objected loud,
and got her expelled from the casbah!

Rene.

-
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: [RFH] Partition table recovery

[Rene Herman]

On 07/23/2007 03:48 PM, Theodore Tso wrote:


On Mon, Jul 23, 2007 at 09:34:25AM +0200, Rene Herman wrote:


That's not quite correct. Logicals have a start field relative to the 
encompassing extended (ie, for me always 1, for others often always 63) and 
the encompassing extended are relative not to the previous extended but to 
the level 0 extended (the one in the MBR). 


This assumes that the extended partition is at the beginning of the
disk, yes?


Err, well, no, that's not what I meant. The start field for the extended 
partition that sits in the primary partitition table (the one in the MBR) is 
absolute, or relative to the start of the disk, but the start field for 
the empty extended partitions that together form the logical partition list 
are relative not to the previous one in the list, but all to this outermost 
extended partition.



Why would anyone do that?  I normally have /dev/hda1 at the beginning of
the disk, and I normally make /dev/hda4 my extended, and place it *after*
partitions at /dev/hda2, /dev/hda3, etc.


... but having said that, I do actually have an extended partition as my 
/dev/hda1 at the beginning of the disk. This is the current layout on my 
main system:


   Device BootStart   End   #sectors  Id  System
/dev/sda1 1 231733119  231733119  85  Linux extended
/dev/sda2   * 231733120 2401217278388608   c  W95 FAT32 (LBA)
/dev/sda3 0 -  0   0  Empty
/dev/sda4 0 -  0   0  Empty
/dev/sda5 2   20971532097152  82  Linux swap
/dev/sda6   2097155  18874370   16777216  83  Linux
/dev/sda7  18874372  35651587   16777216  83  Linux
/dev/sda8  35651589 231733119  196081531  83  Linux

As you can see, everything neatly non-cylinder-aligned, with not a single 
sector wasted ;-) Table sectors at 0 (MBR), 1 (outer extended), 2097154, 
18874371 and 35651588 (list-extendeds).


/dev/sda2 used to be a FreeBSD install (partition type 0xa5), /dev/sda3 a 
MINIX install (type 0x81) and /dev/sda4 the still present FAT32 Windows 98 
partition at the very end of the disk. I removed FreeBSD and MINIX due to 
space shortage...


The reason that I use the first entry for an extended is that I view the 
type Linux Extended simply as Linux: That is, I see 0x85 simply as the 
one and only Linux type with all my Linux data partitions on the logicals 
inside -- very much like 0xa5 is the one FreeBSD type with all its data 
partitions on the slices inside, and 0x81 the one MINIX partition with its 
data partitions on the subpartitions inside.


That is, I've been using a Linux native partitioning scheme where the 
Linux native layout just happens to coincide with a DOS/Windows native layout.


My Linux partition is at the start of the disk since it's the system I use. 
The others are/were there just to boot perhaps a few times a year to check 
some things -- and the start of the disk is the fastest bit, so I certainly 
want my main system to use that.


Anyone find my Native Linux Partitioning Scheme interesting? Designing and 
using a better way than regular logicals to carve up the space inside (such 
as something designed after BSD slices) would work for me as well ;-)



It would be interesting to see how badly modern Windows systems breaks
on this.  If Windows 2000 and above works, and Linux works, then if
other things break it might be quite sufficient to consider them
broken software that we don't need to worry about.


Googling for it, the 2TB limit of DOS partitioning is widely known and there 
would be no point worrying even about the single-bit overflow possibly of 
the list of extendeds...


With 32-bit values (and 512-byte sectors) you can service 2TB -- anything 
above that requires something better than MS-DOS partition tables. 


Well, in about 2-3 years or so we'll seeing having singleton disks
bigger 2TB.  I'm not terribly sanguine about BIOS vendors and OS
providers migrating to something better by then, alas.  Life is sure
going to be interesting.  :-)


And sectors probably larger than 512 bytes. I hope they'll not do _that_ 
until plain old partitions are truly abandoned since before you know it 
someone going to view it as an excuse to keep using this fragile mess ;-)


Rene.

-
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: [RFH] Partion table recovery

[Rene Herman]

On 07/23/2007 10:08 PM, Bill Davidsen wrote:


Al Boldi wrote:


As always, a good friend of mine managed to scratch my partion table 
by cat'ing /dev/full into /dev/sda.  I was able to push him out of the 
way, but at least the first 100MB are gone.  I can probably live 
without the first partion, but there are many partitions after that, 
which I hope should easily be recoverable.


I tried parted, but it's not working out for me.  Does anybody know of 
a simple partition recovery tool, that would just scan the disk for 
lost partions?
  
You have gotten a bunch of thoughts on this, I will just say that plain 
old fdisk -l saved somewhere safe is probably all you need, in human 
readable format. Doesn't do you any good now, but all the complicated 
schemes discussed don't thrill me, I want to be able to see this, and 
recovery by partition table manual rebuild is so rare I would rather do 
it by hand than trust some software I rarely use.


ACK. Or NNAK (Non-NAK) at least...

Rene.

-
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: [RFH] Partition table recovery

[Rene Herman]

On 07/23/2007 03:58 PM, Theodore Tso wrote:

Well, I'm considering this to be a MBR backup scheme, so Minix and BSD 
slices are legacy systems which are out of scope.  If they are busted in

the same way as MBR in terms of not having redundant backups of critical
data, when they have a lot fewer excuses that MBR, and they can address
that issue in their own way.  The number of Linux users that also have
Minix and BSD partitions are a vanishingly small number in any case.


I'd in fact expect quite a few people to have a FreeBSD partition around. 
And MINIX if they are in university and in an operating systems course...


But they should take whatever precautions they want themselves is a valid 
argument.


[ blkid ]


Yeah, good point, I'd have to add that support into blkid.  It's been
on my todo list, but I just haven't gotten around to it yet.


I'll for now stop updating the partbackup thingy as posted. Given that Linux 
 only follows the first extended in the list of extendeds (which sort of 
destroys the nice recursion anyway) it might want to be iterative instead of 
recursive if the thing has a future -- not very important though.



My concern of sysfs is that #1, it won't work on older kernels since
you would need to add new fields to backup what we want,


I'd be okay with that.


and #2, I'm still fundamentally distrustful of sysfs because there isn't
a bright line between what is an exported interface that will never
change, and something which is considered an internal implementation
detail that can change whenever some kernel hacker feels like it.  (Or
when some kernel hacker is careless...)  So as far as I'm concerned sysfs
is a terrible, TERRIBLE way to export a published interface where we 
promise stability to userspace.


Oh come on, that's going overboard a bit, it's not all _that_ bad! Finding 
say sda will be possible without breaking too many times. Admittedly, the 
kernel's partittion scanning order is also not likely to change as it would 
certainly break userspace, but code duplication, with the possiblity of bugs 
slipping in at least userspace-ways (considering the kernel the reference no 
matter what it does) is a concern. Somewhat. A little.



So I'd just as soon do this in userspace; after all, the entire partition
manager (and there are multiple ones; fdisk, sfdisk, gpart, etc.) all in
userspace, and that needs to be in synch with the kernel partition
reading code anyway.  So one more userspace implementation is in my mind
much cleaner than trying to push the needed functionality into sysfs, and
then hoping against hope that it doesn't accidentally change in the
future.


* rene envisions /lib/libpart.so...

Not to mention my Grand Visions of a totally new Linux native partitioning 
scheme probably modelled after BSD slices (as also mentioned in a previous 
message just now). Or perhaps LVM already fills that role comfortably. It's 
certainly what I hear everyone talking about these days.


Rene.
-
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: -mm merge plans for 2.6.23

[Rene Herman]

On 07/25/2007 06:06 AM, Nick Piggin wrote:


Ray Lee wrote:


Anyway, my point is that I worry that tuning for an unusual and 
infrequent workload (which updatedb certainly is), is the wrong way to 
go.


Well it runs every day or so for every desktop Linux user, and it has
similarities with other workloads.


It certainly doesn't run for me ever. Always kind of a that's not the 
point comment but I just keep wondering whenever I see anyone complain 
about updatedb why the _hell_ they are running it in the first place. If 
anyone who never uses locate for anything simply disable updatedb, the 
problem will for a large part be solved.


This not just meant as a cheap comment; while I can think of a few similar 
loads even on the desktop (scanning a browser cache, a media player indexing 
a large amount of media files, ...) I've never heard of problems _other_ 
than updatedb. So just junk that crap and be happy.


Rene.
-
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: -mm merge plans for 2.6.23

[Rene Herman]

On 07/25/2007 07:12 AM, [EMAIL PROTECTED] wrote:


On Wed, 25 Jul 2007, Rene Herman wrote:


It certainly doesn't run for me ever. Always kind of a that's not the 
point comment but I just keep wondering whenever I see anyone 
complain about updatedb why the _hell_ they are running it in the 
first place. If anyone who never uses locate for anything simply 
disable updatedb, the problem will for a large part be solved.


This not just meant as a cheap comment; while I can think of a few 
similar loads even on the desktop (scanning a browser cache, a media 
player indexing a large amount of media files, ...) I've never heard 
of problems _other_ than updatedb. So just junk that crap and be happy.


but if you do use locate then the alturnative becomes sitting around and 
waiting for find to complete on a regular basis.


Yes, but what's locate's usage scenario? I've never, ever wanted to use it. 
When do you know the name of something but not where it's located, other 
than situations which which wouldn't cover and after just having 
installed/unpacked something meaning locate doesn't know about it yet either?


Rene.

-
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: -mm merge plans for 2.6.23

[Rene Herman]

On 07/25/2007 06:46 AM, [EMAIL PROTECTED] wrote:

you could make a synthetic test by writing a memory hog that allocates 
3/4 of your ram then pauses waiting for input and then randomly accesses 
the memory for a while (say randomly accessing 2x # of pages allocated) 
and then pausing again before repeating


Something like this?

run two of these, alternating which one is running at any one time. time 
how long it takes to do the random accesses.


the difference in this time should be a fair example of how much it 
would impact the user.


Notenotenote, not sure what you're going to show with it (times are simply 
as horrendous as I'd expect) but thought I'd try to inject something other 
than steaming cups of 4-letter beverages.


Rene.
/* gcc -W -Wall -o hog hog.c */

#include stdlib.h
#include stdio.h

#include sys/time.h
#include unistd.h

int main(void)
{
int pages, pagesize, i;
unsigned char *mem;
struct timeval tv;

pages = sysconf(_SC_PHYS_PAGES);
if (pages  0) {
perror(_SC_PHYS_PAGES);
return EXIT_FAILURE;
}
pages = (3 * pages) / 4;

pagesize = sysconf(_SC_PAGESIZE);
if (pagesize  0) {
perror(_SC_PAGESIZE);
return EXIT_FAILURE;
}

mem = malloc(pages * pagesize);
if (!mem) {
fprintf(stderr, out of memory\n);
return EXIT_FAILURE;
}
for (i = 0; i  pages; i++)
mem[i * pagesize] = 0;

gettimeofday(tv, NULL);
srand((unsigned int)tv.tv_sec);

while (1) {
struct timeval start;

getchar();

gettimeofday(start, NULL);
for (i = 0; i  2 * pages; i++)
mem[(rand() / (RAND_MAX / pages + 1)) * pagesize] = 0;
gettimeofday(tv, NULL);

timersub(tv, start, tv);
printf(%lu.%lu\n, tv.tv_sec, tv.tv_usec);
}

return EXIT_SUCCESS;
}

Re: -mm merge plans for 2.6.23

[Rene Herman]

On 07/25/2007 09:14 AM, [EMAIL PROTECTED] wrote:


On Wed, 25 Jul 2007 07:30:37 +0200, Rene Herman said:


Yes, but what's locate's usage scenario? I've never, ever wanted to use
it. When do you know the name of something but not where it's located,
other than situations which which wouldn't cover and after just
having installed/unpacked something meaning locate doesn't know about
it yet either?


My favorite use - with 5 Fedora kernels and as many -mm kernels on my
laptop, doing a 'locate moby' finds all the moby.c and moby.o and moby.ko
for the various releases.


Supposing you know the path in one tree, you know the path in all of them, 
right? :-?



You want hard numbers? Here you go - 'locate' versus 'find'


These are ofcourse not necesary. If you discount the time updatedb itself 
takes it's utterly obvious that _if_ you use it, it's going to be wildly 
faster than find.


Regardless, I'll stand by [by disabling updatedb] the problem will for a 
large part be solved as I expect approximately 94.372 percent of Linux 
desktop users couldn't care less about locate.


Rene.
-
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: -mm merge plans for 2.6.23

[Rene Herman]

On 07/25/2007 10:07 AM, [EMAIL PROTECTED] wrote:


On Wed, 25 Jul 2007, Rene Herman wrote:



Something like this?


[ ... ]

when the swap readahead is enabled does it make a significant difference 
in the time to do the random access?


I don't use swap prefetch (nor -ck or -mm). If someone who has the patch 
applied waits to hit enter until swap prefetch has prefetched it all back in 
again, it certainly will.


Swap prefetch's potential to do larger reads back from swapspace than a 
random segfaulting app could well be very significant. Reads are dwarved by 
seeks. If this program does what you wanted, please use it to show us.


Rene.
-
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: -mm merge plans for 2.6.23

[Rene Herman]

On 07/25/2007 10:28 AM, Ingo Molnar wrote:

Regardless, I'll stand by [by disabling updatedb] the problem will 
for a large part be solved as I expect approximately 94.372 percent 
of Linux desktop users couldn't care less about locate.


i think that approach is illogical: because Linux mis-handled a mixed 
workload the answer is to ... remove a portion of that workload?


No. It got snipped but I introduced the comment by saying it was a that's 
not the point kind of thing. Sometimes things that aren't the point are 
still true though and in the case of Linux desktop users complaining about 
updatedb runs, a comment that says that for many an obvious solution would 
be to stop running the damned thing is not in any sense illogical.


Also note I'm not against swap prefetch or anything. I don't use it and do 
not believe I have a pressing need for it, but do suspect it has potential 
to make quite a bit of difference on some things -- if only to drastically 
reduce seeks if it means it's swapping in larger chunks than a randomly 
faulting program would.


Rene.
-
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: -mm merge plans for 2.6.23

[Rene Herman]

On 07/25/2007 10:33 AM, [EMAIL PROTECTED] wrote:

I haven't used swap prefetch either, the call was put out for what 
could be used to test the performance, and I was suggesting a test.


if nobody else follows up on this I'll try to get some time to test it 
myself in a day or two.


this assumes that this isn't ruled an invalid test in the meantime.


Let's save a little time and guess. While two instances of the hog are 
running no physical memory is free (as together they take up 1.5x physical) 
meaning that swap-prefetch wouldn't get a change to do anything and wouldn't 
make a difference. As such, the two instances test as you suggested would in 
fact not be testing anything it seems.


However, if you quit one, and idle long enough to continue with the other 
one until swap-prefetch prefetched all its memory back in, it should be a 
difference on the order of minutes, even total if swap prefetch fetched it 
back in without seeking al over swap-space, and total isn't applicable if 
the idle time really is free.


A program randomly touching single pages all over memory is a contrived 
worst case scenario and not a real-world issue. It is a boundary condition 
though, and it's simply quite impossible to think of any example where 
swap-prefetch would _not_ give you a snappier feeling machine after you've 
been idling.


So really the only question would seem to be -- does it hurt any if you have 
_not_ been?


Rene.

-
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: -mm merge plans for 2.6.23

[Rene Herman]

On 07/25/2007 01:34 PM, Ingo Molnar wrote:

and the fact is: updatedb discards a considerable portion of the cache 
completely unnecessarily: on a reasonably complex box no way do all the 
inodes and dentries fit into all of RAM, so we just trash everything.


Okay, but unless I've now managed to really quite horribly confuse myself, 
that wouldn't have anything to do with _swap_ prefetch would it?


Rene.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ck] Re: -mm merge plans for 2.6.23

[Rene Herman]

On 07/25/2007 12:53 PM, Jos Poortvliet wrote:

On 7/25/07, *Rene Herman* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:



Also note I'm not against swap prefetch or anything. I don't use it and
do not believe I have a pressing need for it, but do suspect it has 
potential to make quite a bit of difference on some things -- if only

to drastically reduce seeks if it means it's swapping in larger chunks
than a randomly faulting program would.


I wonder what your hardware is. Con talked about the diff in hardware 
between most endusers and the kernel developers. 


I'm afraid you will need to categorize me more as an innocent bystander than 
a kernel developer and, as such, I have an endusery x86 with 768M (but I 
still think of myself as one of the cool kids!)



Yes, swap prefetch doesn't help if you have 3 GB ram, but it DOES do a
lot on a 256 mb laptop...


Rather, it does not help if you are not swapping or idling. Probably largely 
due to me being a rather serial person I seem to never even push my git tree 
from cache. Hence my belief that I don't have a pressing need for it.


Taking a laptop as an example is interesting in itself by the way since a 
spundown disk (most applicable to laptops) is an argument against swap 
prefetch even when idle and when I'm not mistaken the feature actually 
disables itself when the machine's set to laptop mode...



After using OO.o, the system continues to be slow for a long time. With
swap prefetch, it's back up speed much faster. Con has showed a benchmark
for this with speedups of 10 times and more, users mentioned they liked
it.


After using and quiting OO.o. If you simply don't have any memory free to 
prefetch into swap prefetch won't help any. The fact that it helps the case 
of OO.o having pushed out firefox is fairly obvious.



Nick has been talking about 'fixing the updatedb thing' for years now, no
patch yet. Besides, he won't fix OO.o nor all other userspace stuff - so
actually, he does NOT even promise an alternative. Not that I think
fixing updatedb would be cool, btw - it sure would, but it's no reason
not to include swap prefetch - it's mostly unrelated.


Well, the trouble at least to some is that they indeed seem to be rather 
unrelated. Why does the updatedb run even cause swapout? (itself ofcourse a 
pre-condition for swap-prefetch to help).


I think everyone with 1 gb ram should stop saying 'I don't need it' 
because that's obvious for that hardware. Just like ppl having a dual- 
or quadcore shouldn't even talk about scheduler interactivity stuff...


Actually, interactivity is largely about latency and latency is largely or 
partly independent of CPU speed -- if something's keeping the system from 
scheduling for too long it's likely that it's hogging the CPU for a fixed 
number of usecs and those pass in the same amount of time on all CPUs (we 
hope...).


But that's a tangent anyway. I'm just glad that I get to say that I believe 
I don't need it with my 768M!


Apparently, it didn't get in yet - and I find it hard to believe Andrew 
holds swapprefetch for reasons like the above. So it must be something 
else.


Nick is saying tests have already proven swap prefetch to be helpfull, 
that's not the problem. He calls the requirements to get in 'fuzzy'. OK.
Beer is fuzzy, do we need to offer beer to someone? If Andrew promises 
to come to FOSDEM again next year, I'll offer him a beer, if that 
helps... Anything else? A nice massage?


Personally I'd go for sexual favours directly (but then again, I always do).

But please also note that I even _literally_ said above that I myself am not 
against swap-prefetch or anything and yet I get what appears to be an least 
somewhat adversary rant directed at me. Which in itself is fine, but not too 
helpful...


Nick Piggin is the person to convince it seems and if I've read things right 
(I only stepped into this thing at the updatedb mention, so maybe I haven't) 
his main question is _why_ the hell it helps updatedb. As long as you don't 
know this, then even a solution that helps could be papering over a problem 
which you'd much rather fix at the root rather than at the symptom.


Rene.

-
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: howto get a patch merged (WAS: Re: -mm merge plans for 2.6.23)

[Rene Herman]

On 07/25/2007 05:30 PM, Kacper Wysocki wrote:


main question is _why_ the hell it helps updatedb.



Is that what [ ... ]


And there we go again -- off into blabber-land. Why does swap-prefetch help 
updatedb? Or doesn't it? And if it doesn't, why should anyone trust anything 
else someone who said it does says?


Rene.
-
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: updatedb

[Rene Herman]

On 07/26/2007 09:08 AM, Bongani Hlope wrote:


On Thursday 26 July 2007 08:56:59 Rene Herman wrote:


Great. Now concentrate on the swpd column, as it's the only thing 
relevant here. The fact that an updatedb run fills/replaces caches is 
completely and utterly unsurprising and not something swap-prefetch

helps with. The only thing it does is bring back stuff from _swap_.


;)

I have 2Gb of RAM and I never ever touched swap on all my work loads. I
was just showing the behavior of updatedb on my desktop. I have never
even looked at the swap-prefetch patch (for obvious reasons).


I see... thanks for the report :)


I think people should also look at their /proc/sys/vm/overcommit_ratio


In the sense that current stuff might be evicted earlier with no or little 
overcommit?


Rene.

-
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: updatedb

[Rene Herman]

On 07/26/2007 08:23 AM, Andika Triwidada wrote:


On 7/26/07, Rene Herman [EMAIL PROTECTED] wrote:



RAM intensive? If I run updatedb here, it never grows itself beyond 2M.
Yes, two. I'm certainly willing to accept that me and my systems are 
possibly not the reference but assuming I'm _very_ special hasn't done

much for me either in the past.


Might be insignificant, but updatedb calls find (~2M) and sort (~26M).


It does? My updatedb certainly doesn't seem to (slackware 12.0). It's using 
Secure Locate. Different distributions using different versions of locate 
it seems?


Rene.
-
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: i386-show-unhandled-signals-v3

[Rene Herman]

On 07/26/2007 01:25 AM, Andrew Morton wrote:


On Wed, 25 Jul 2007 14:07:56 -0700
Masoud Sharbiani [EMAIL PROTECTED] wrote:



This is rate limited; Do you need me to rewrite it with it being
disabled by default?


Yes please.

Look: if there's a way in which an unprivileged user can trigger a printk
we fix it, end of story. I don't know why this even slightly controversial.


[EMAIL PROTECTED]:/tmp$ su -c dmesg -c /dev/null
[EMAIL PROTECTED]:/tmp$ cdparanoia -B

[ ... ]

[EMAIL PROTECTED]:/tmp$ dmesg | wc -l
158
[EMAIL PROTECTED]:/tmp$ dmesg | tail -20
sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing data in;
   program cdparanoia not setting count and/or reply_len properly
printk: 252 messages suppressed.
sg_write: data in/out 16464/16464 bytes for SCSI command 0xbe--guessing data in;
   program cdparanoia not setting count and/or reply_len properly
printk: 245 messages suppressed.
sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing data in;
   program cdparanoia not setting count and/or reply_len properly
printk: 243 messages suppressed.
sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing data in;
   program cdparanoia not setting count and/or reply_len properly
printk: 242 messages suppressed.
sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing data in;
   program cdparanoia not setting count and/or reply_len properly
printk: 255 messages suppressed.
sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing data in;
   program cdparanoia not setting count and/or reply_len properly
printk: 242 messages suppressed.
sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing data in;
   program cdparanoia not setting count and/or reply_len properly

cdparanoia does require access to the /dev/sg? that corresponds to /dev/cdrom 
but at least udev (here) makes that node be a (root,cdrom) b-rw-rw--- device 
(and requiring root privileges to rip CDs would certainly not be nice).


Rene.
-
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: i386-show-unhandled-signals-v3

[Rene Herman]

On 07/26/2007 12:16 PM, Alan Cox wrote:


On Thu, 26 Jul 2007 11:46:23 +0200
Andi Kleen [EMAIL PROTECTED] wrote:


Look: if there's a way in which an unprivileged user can trigger a printk
we fix it, end of story. 

I'm firmly against disabling it on x86-64 by default. The printks are extremly
useful and have found many bugs in the past.


Then add the rate limiting by default.


The messages were rate limited -- Andrew said they couldn't be on default even 
rate limited.


Rene.
-
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: updatedb

[Rene Herman]

On 07/26/2007 11:58 AM, Björn Steinbrink wrote:


Will now go and see what happens if I play with swappiness.


I in fact managed to overlook _all_ of swappiness (*) and was quite frankly 
under the impression that Linux would simply never swap anything out to make 
room for cache. Which is basic enough a misunderstanding that I'll go sulk 
in a corner now.


Rene.

(*)

$ grep -ri swappiness Documentation
$

Sigh...
-
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/

updatedb

[Rene Herman]

On 07/25/2007 07:15 PM, Robert Deaton wrote:


On 7/25/07, Rene Herman [EMAIL PROTECTED] wrote:


And there we go again -- off into blabber-land. Why does swap-prefetch 
help updatedb? Or doesn't it? And if it doesn't, why should anyone 
trust anything else someone who said it does says?


I don't think anyone has ever argued that swap-prefetch directly helps 
the performance of updatedb in any way


People have argued (claimed, rather) that swap-prefetch helps their system 
after updatedb has run -- you are doing so now.



however, I do recall people mentioning that updatedb, being a ram
intensive task, will often cause things to be swapped out while it runs
on say a nightly cronjob.


Problem spot no. 1.

RAM intensive? If I run updatedb here, it never grows itself beyond 2M. Yes, 
two. I'm certainly willing to accept that me and my systems are possibly not 
the reference but assuming I'm _very_ special hasn't done much for me either 
in the past.


The thing updatedb does do, or at least has the potential to do, is fill 
memory with cached inodes/dentries but Linux does not swap to make room for 
caches. So why will updatedb often cause things to be swapped out?


[ snip ]


Swap prefetch, on the other hand, would have kicked in shortly after
updatedb finished, leaving the applications in swap for a speedy
recovery when the person comes back to their computer.


Problem spot no. 2.

If updatedb filled all of RAM with inodes/dentries, that RAM is now used 
(ie, not free) and swap-prefetch wouldn't have anywhere to prefetch into so 
would _not_ have kicked in.


So what's happening? If you sit down with a copy op top in one terminal 
and updatedb in another, what does it show?


Rene.

-
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: updatedb

[Rene Herman]

On 07/26/2007 08:39 AM, Bongani Hlope wrote:


On Thursday 26 July 2007 05:59:53 Rene Herman wrote:



So what's happening? If you sit down with a copy op top in one terminal
and updatedb in another, what does it show?



Just tested that, there's a steady increase in the useage of buff


Great. Now concentrate on the swpd column, as it's the only thing relevant 
here. The fact that an updatedb run fills/replaces caches is completely and 
utterly unsurprising and not something swap-prefetch helps with. The only 
thing it does is bring back stuff from _swap_.


Rene.

-
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: updatedb

[Rene Herman]

On 07/27/2007 02:46 AM, Jesper Juhl wrote:


On 26/07/07, Andika Triwidada [EMAIL PROTECTED] wrote:


Might be insignificant, but updatedb calls find (~2M) and sort (~26M). 
Definitely not RAM intensive though (RAM is 1GB).


That doesn't match my box at all :


[ ... ]


This is a Slackware Linux 12.0 system.


Yes, already identified that there are more updatedb's around. We are using 
Secure Locate and others simply the locate from the GNU findutils. Either 
version does not itself use significant memory though and seems irrelevant 
to the orginal swap-prefetch issue -- if updatedb filled memory with inodes 
and dentries the memory is no longer free and swap-prefetch can't prefetch 
anything.


The remaining issue of updatedb unnecessarily blowing away VFS caches is 
being discussed (*) in a few thread-branches still running.


Rene.

(*) I so much wanted to say buried.

-
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: updatedb

[Rene Herman]

On 07/27/2007 09:54 AM, Mike Galbraith wrote:


On Fri, 2007-07-27 at 08:00 +0200, Rene Herman wrote:

The remaining issue of updatedb unnecessarily blowing away VFS caches is 
being discussed (*) in a few thread-branches still running.


If you solve that, the swap thing dies too, they're one and the same
problem.


I still wonder what the the swap thing is though. People just kept saying 
that swap-prefetch helped which would seem to indicate their problem didnt 
have anything to do with updatedb.


Also, I know shit about the VFS so this may well be not very educated but to 
me something like FADV_NOREUSE on a dirfd sounds like a much more promising 
approach than the convoluted userspace schemes being discussed, if only 
because it'll actually be implemented/used.


Rene.

-
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: updatedb

[Rene Herman]

On 07/27/2007 01:48 PM, Mike Galbraith wrote:


physical ram.  If it really does use only free ram, that indeed sounds
pretty pointless.


Con's quote from a bit below that seems to confirm the only free nicely.


I believe the users who say their apps really do get paged back in
though, so suspect that's not the case.


Stopping the bush-circumference beating, I do not. -ck (and gentoo) have 
this massive Calimero thing going among their users where people are much 
less interested in technology than in how the nasty big kernel meanies are 
keeping them down (*).


Nick Piggin has been unable to get anyone to substantiate anything it seems 
and even this thread alone (and I privately) received a few oh, heh, sorry, 
I don't actually have a friggin' clue what I'm talking about responses. As 
such, I believe it's fairly safe to dump the updatedb thing in the garbage 
as not a practical problem.


Leaves the issue of for example a midnight backup run that could very well 
itself grow large enough to leave massive amounts of free memory at exit 
which swap-prefetch _would_ help with. I haven't much opinion on how 
important such situations are but trying to do something to help those seems 
sensible in itself.


Rene.

(*) which isn't to say that you guys aren't in fact nasty big kernel meanies 
ofcourse.


-
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: updatedb

[Rene Herman]

On 07/27/2007 11:26 AM, Mike Galbraith wrote:


On Fri, 2007-07-27 at 10:28 +0200, Rene Herman wrote:



I still wonder what the the swap thing is though. People just kept
saying that swap-prefetch helped which would seem to indicate their
problem didnt have anything to do with updatedb.


I haven't rummaged around in the VM in quite a long while, so don't know 
exactly where the balance lies any more, and have never looked at 
swap-prefetch, but the mechanism of how swap-prefetch can help the 
morning after syndrome seems simple enough:


As far as I've googled things together, the below scenario won't happen:

Reclaim (swapout) a slew of application pages because there are 
truckloads of utterly bored pages laying about when updatedb comes along 
and introduces memory pressure in the middle of the night.


Ack (*)


Updatedb finishes, freeing some ram (doesn't matter how much)


Will be very little and swap-prefetch at least in its current form needs 
more than very little to start doing anything:


http://ck.kolivas.org/patches/swap-prefetch/2.6.21-swap_prefetch-38.patch

| /*
|  * Set max number of entries to 2/3 the size of physical ram  as we
|  * only ever prefetch to consume 2/3 of the ram.
|  */

However, okay, let's just ignore that and pretend it kicks in even with the 
little free memory updatedb itself left behind when it finished:


swap-prefetch detects idle CPU, and begins faulting swapped out pages 
back in. In the process of doing so, memory pressure is generated, and

now these freshly accessed pages are a less lovely target than the now
aging VFS caches that updatedb bloated up, so they shrink back down
enough that the balance you had before updatedb ran is restored...


The story now again breaks down here. Over at:

http://lkml.org/lkml/2007/2/9/112

we have swap-prefetch's author saying:

| swap prefetch stores the data at the tail end of the lru list which
| means that even if you do want to use that ram for something else,
| the prefetched pages will be immediately dropped.

So those aging VFS caches will never be replaced by anything prefetched it 
seems and any prefetching stops after the couple of pages that updatedb 
itself freed have been taken again.


A subsequent bit in that same message reads:

| It can't help the updatedb scenario. Updatedb leaves the ram full and
| swap prefetch wants to cost as little as possible so it will never
| move anything out of ram in preference for the pages it wants to swap
| back in.

which I'll take as confirmation.


with the notable exception that cached data is now toast, so what you
gained by faulting god knows how frequently used pages back in isn't
_necessarily_ going to help you.


Also file-backed pages (such as the program binaries itself). However, _if_ 
prefetching were to take place, I'd be okay assuming it helps.



Heck, it could even step on what was left of your cached working set
after updatedb finished.


Given swap-prefetch's focus on being as free as possible I don't believe it 
should hurt any. And yes, it's always going to help _some_ workload shifts 
and as far as I'm concerned is a makes sense kind of tweak even if it's 
not the be all end all so again, not against swap-prefetch or its merger or 
anything...


Also, I know shit about the VFS so this may well be not very educated but to 
me something like FADV_NOREUSE on a dirfd sounds like a much more promising 
approach than the convoluted userspace schemes being discussed, if only 
because it'll actually be implemented/used.


I like Andrew's mention of a future option... put that sucker and
everybody who looks like him in a resource limited container.


As to the (*) above -- now that I actually know about the swappiness 
thing, shouldn't setting that to 0 around updatedb runs really be quite 
effective and if it's not, is there anything to be fixed there? Bjoern 
Steinbrink (added to CC) earlier in this thread tried that and said stuff 
went weird.


Rene.

-
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: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]

[Rene Herman]

On 07/27/2007 07:45 PM, Daniel Hazelton wrote:


Updatedb or another process that uses the FS heavily runs on a users
256MB P3-800 (when it is idle) and the VFS caches grow, causing memory
pressure that causes other applications to be swapped to disk. In the
morning the user has to wait for the system to swap those applications
back in.

Questions about it:
Q) Does swap-prefetch help with this? 
A) [From all reports I've seen (*)] Yes, it does. 


No it does not. If updatedb filled memory to the point of causing swapping 
(which noone is reproducing anyway) it HAS FILLED MEMORY and swap-prefetch 
hasn't any memory to prefetch into -- updatedb itself doesn't use any 
significant memory.


Here's swap-prefetch's author saying the same:

http://lkml.org/lkml/2007/2/9/112

| It can't help the updatedb scenario. Updatedb leaves the ram full and
| swap prefetch wants to cost as little as possible so it will never
| move anything out of ram in preference for the pages it wants to swap
| back in.

Now please finally either understand this, or tell us how we're wrong.

Rene.

-
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: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]

[Rene Herman]

On 07/27/2007 10:28 PM, Daniel Hazelton wrote:


Check the attitude at the door then re-read what I actually said:


Attitude? You wanted attitude dear boy?


Updatedb or another process that uses the FS heavily runs on a users
256MB P3-800 (when it is idle) and the VFS caches grow, causing memory
pressure that causes other applications to be swapped to disk. In the
morning the user has to wait for the system to swap those applications
back in.


I never said that it was the *program* itself - or *any* specific program (I 
used Updatedb because it has been the big name in the discussion) - doing 
the filling of memory. I actually said that the problem is that the kernel's 
caches - VFS and others - will grow *WITHOUT* *LIMIT*, filling all available 
memory. 


WHICH SWAP-PREFETCH DOES NOT HELP WITH.
WHICH SWAP-PREFETCH DOES NOT HELP WITH.
WHICH SWAP-PREFETCH DOES NOT HELP WITH.

And now finally get that through your thick scull or shut up, right fucking now.

You want to know what causes the problem? The current design of the caches. 
They will extend without much limit, to the point of actually pushing pages 
to disk so they can grow even more. 


Due to being a generally nice guy, I am going to try _once_ more to try and 
make you understand. Not twice, once. So pay attention. Right now.


Those caches are NOT causing any problem under discussion. If any caches 
grow to the point of causing swap-out, they have filled memory and 
swap-prefetch cannot and will not do anything since it needs free (as in not 
occupied by caches) memory. As such, people maintaining that swap-prefetch 
helps their situation are not being hit by caches.


The only way swap-prefetch can (and will) do anything is when something that 
by itself takes up lots of memory runs and exits. So can we now please 
finally drop the fucking red herring and start talking about swap-prefetch?


If we accept that some of the people maintaining that swap-prefetch helps 
them are not in fact deluded -- a bit of a stretch seeing as how not a 
single one of them is substantiating anything -- we have a number of 
slightly different possibilities for something in the above.


-- 1)

It could be an inefficient updatedb. Although he isn't experiencing the 
problem, Bjoern Steinbrink is posting numbers (w!) that show that at 
least the GNU version spawns a large memory sort process meaning that on a 
low-memory box updatedb itself can be what causes the observed problem.


While in this situation switching to a different updatedb (slocate, mlocate) 
obviously makes sense it's the kind of situation where swap-prefetch will help.


-- 2)

It could be something else entirely such as a backup run. I suppose people 
would know if they were running anything of the sort though and wouldn't 
blaim anything on updatedb.


Other than that, it's again the situation where swap-prefetch would help.

-- 3)

The something else entirely can also run _after_ updatedb, kicking out the 
VFS caches and leaving free memory upon exit. I still suppose the same thing 
as under (2) but this is the only way how updatedb / VFS caches can even be 
part of any problem, if the _combined_ memory pressure is just enough to 
make the difference.


The direct problem is still just the something else entirely and needs 
someone affected to tell us what it is.


I already did. You completely ignored it because I happened to use the magic 
words updatedb and swap prefetch. 


No I did not. This thread is about swap-prefetch and you used the magic 
words VFS caches. I don't give a fryin' fuck if their filling is caused by 
updatedb or the cat sleeping on the find /enter keys on your keyboard, 
they're still not causing anything swap-prefetch helps with.


This thread has seen input from a selection of knowledgeable people and 
Morton was even running benchmarks to look at this supposed VFS cache 
problem and not finding it. The only further input this thread needs is 
someone affected by the supposed problem.


Which I ofcourse notice in a followup of yours you are not either -- you're 
just here to blabber, not to solve anything.


Rene.

-
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 with IDE on linux 2.6.22.X

[Rene Herman]

On 08/22/2007 01:23 PM, Alan Cox wrote:

The old SATA driver available from the IDE menu also does not support your 
chip, so I don't believe there are any workarounds -- you'll need the issue 
fixed.


What issue ?

From the report its quite simple - enable the correct CONFIG_ATA based
drivers and it should all work fine.


He has a SATA harddrive and an IDE DVD drive. When he compiles with 
CONFIG_ATA_PIIX (a driver which advertises both SATA and PATA in its 
description) his drive works, his DVD does not. Is that not the correct 
driver? Does he need something else? How does he get his DVD to work?


Rene.

-
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 with IDE on linux 2.6.22.X

[Rene Herman]

On 08/22/2007 06:23 PM, Lennart Sorensen wrote:


On Wed, Aug 22, 2007 at 05:48:52PM +0200, Rene Herman wrote:


He has a SATA harddrive and an IDE DVD drive. When he compiles with 
CONFIG_ATA_PIIX (a driver which advertises both SATA and PATA in its 
description) his drive works, his DVD does not. Is that not the correct 
driver? Does he need something else? How does he get his DVD to work?


Well of course the DVD should show up as /dev/sr0 or scd0 with the new
driver, not the /dev/hd? name.  And scsi cdrom support is required too.


Obviously. Looking back through the report, him having SCSI CD-ROM support 
wasn't actually explicit so that might in fact be the problem but his 
self-compiled 2.6.20.15 worked and a 2.6.22 based Open SuSE Live CD does not 
(and he does have SCSI disk support, which suggests he will've likely also 
have thought of SCSI CD-ROM support) so it does not seem to be.


José: do you have SCSI CD-ROM support compiled in? What are the ATA/SCSI 
related messages in the output of dmesg when you compile with the 
CONFIG_ATA_PIIX driver, SCSI disk and SCSI CD-ROM support (and nothing from 
the old IDE menu)?


Rene.

-
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 with IDE on linux 2.6.22.X

[Rene Herman]

On 08/28/2007 02:44 AM, José Luis Patiño Andrés wrote:


Okay Rene, I activated SCSI CD-ROM support in kernel config and now all
works again. It's strange, because I never used this option to get my DVD
device on.


Sheesh. How could anyone _not_ understand you need SCSI CD-ROM support for 
your IDE DVD-RW drive...


Rene Sigh Herman

-
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: CFS review

[Rene Herman]

On 08/29/2007 05:57 PM, Keith Packard wrote:


With X server 1.3, I'm getting consistent crashes with two glxgear
instances running. So, if you're getting any output, it's better than my
situation.


Before people focuss on software rendering too much -- also with 1.3.0 (and
a Matrox Millenium G550 AGP, 32M) glxgears also works decidedly crummy using
hardware rendering. While I can move the glxgears window itself, the actual
spinning wheels stay in the upper-left corner of the screen and the movement
leaves a non-repainting trace on the screen. Running a second instance of
glxgears in addition seems to make both instances unkillable  -- and when
I just now forcefully killed X in this situation (the spinning wheels were
covering the upper left corner of all my desktops) I got the below.

Kernel is 2.6.22.5-cfs-v20.5, schedule() is in the traces (but that may be
expected anyway).

BUG: unable to handle kernel NULL pointer dereference at virtual address 
0010
 printing eip:
c10ff416
*pde = 
Oops:  [#1]
PREEMPT
Modules linked in: nfsd exportfs lockd nfs_acl sunrpc nls_iso8859_1 nls_cp437 vfat fat 
nls_base

CPU:0
EIP:0060:[c10ff416]Not tainted VLI
EFLAGS: 00210246   (2.6.22.5-cfs-v20.5-local #5)
EIP is at mga_dma_buffers+0x189/0x2e3
eax:    ebx: efd07200   ecx: 0001   edx: efc32c00
esi:    edi: c12756cc   ebp: dfea44c0   esp: dddaaec0
ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
Process glxgears (pid: 1775, ti=dddaa000 task=e9daca60 task.ti=dddaa000)
Stack: efc32c00  0004 e4c3bd20 c10fa54b e4c3bd20 efc32c00 
   0004     0001 0001 bfbdb8bc
   bfbdb8b8  c10ff28d 0029 c12756cc dfea44c0 c10f87fc bfbdb844
Call Trace:
 [c10fa54b] drm_lock+0x255/0x2de
 [c10ff28d] mga_dma_buffers+0x0/0x2e3
 [c10f87fc] drm_ioctl+0x142/0x18a
 [c1005973] do_IRQ+0x97/0xb0
 [c10f86ba] drm_ioctl+0x0/0x18a
 [c10f86ba] drm_ioctl+0x0/0x18a
 [c105b0d7] do_ioctl+0x87/0x9f
 [c105b32c] vfs_ioctl+0x23d/0x250
 [c11b533e] schedule+0x2d0/0x2e6
 [c105b372] sys_ioctl+0x33/0x4d
 [c1003d1e] syscall_call+0x7/0xb
 ===
Code: 9a 08 03 00 00 8b 73 30 74 14 c7 44 24 04 28 76 1c c1 c7 04 24 49 51 23 c1 e8 b0 74 
f1 ff 8b 83 d8 00 00 00 83 3d 1c 47 30 c1 00 8b 40 10 8b a8 58 1e 00 00 8b 43 28 8b b8 
64 01 00 00 74 32 8b

EIP: [c10ff416] mga_dma_buffers+0x189/0x2e3 SS:ESP 0068:dddaaec0
BUG: unable to handle kernel NULL pointer dereference at virtual address 
0010
 printing eip:
c10ff416
*pde = 
Oops:  [#2]
PREEMPT
Modules linked in: nfsd exportfs lockd nfs_acl sunrpc nls_iso8859_1 nls_cp437 vfat fat 
nls_base

CPU:0
EIP:0060:[c10ff416]Not tainted VLI
EFLAGS: 00210246   (2.6.22.5-cfs-v20.5-local #5)
EIP is at mga_dma_buffers+0x189/0x2e3
eax:    ebx: efd07200   ecx: 0001   edx: efc32c00
esi:    edi: c12756cc   ebp: dfea4780   esp: e0552ec0
ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
Process glxgears (pid: 1776, ti=e0552000 task=c19ec000 task.ti=e0552000)
Stack: efc32c00  0003 efc64b40 c10fa54b efc64b40 efc32c00 
   0003     0001 0001 bf8dbdcc
   bf8dbdc8  c10ff28d 0029 c12756cc dfea4780 c10f87fc bf8dbd54
Call Trace:
 [c10fa54b] drm_lock+0x255/0x2de
 [c10ff28d] mga_dma_buffers+0x0/0x2e3
 [c10f87fc] drm_ioctl+0x142/0x18a
 [c11b53f6] preempt_schedule+0x4e/0x5a
 [c10f86ba] drm_ioctl+0x0/0x18a
 [c10f86ba] drm_ioctl+0x0/0x18a
 [c105b0d7] do_ioctl+0x87/0x9f
 [c105b32c] vfs_ioctl+0x23d/0x250
 [c11b52a9] schedule+0x23b/0x2e6
 [c11b533e] schedule+0x2d0/0x2e6
 [c105b372] sys_ioctl+0x33/0x4d
 [c1003d1e] syscall_call+0x7/0xb
 ===
Code: 9a 08 03 00 00 8b 73 30 74 14 c7 44 24 04 28 76 1c c1 c7 04 24 49 51 23 c1 e8 b0 74 
f1 ff 8b 83 d8 00 00 00 83 3d 1c 47 30 c1 00 8b 40 10 8b a8 58 1e 00 00 8b 43 28 8b b8 
64 01 00 00 74 32 8b

EIP: [c10ff416] mga_dma_buffers+0x189/0x2e3 SS:ESP 0068:e0552ec0
[drm:drm_release] *ERROR* Device busy: 2 0

Rene.
-
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: CFS review

[Rene Herman]

On 08/29/2007 09:56 PM, Rene Herman wrote:

Realised the BUGs may mean the kernel DRM people could want to be in CC...


On 08/29/2007 05:57 PM, Keith Packard wrote:


With X server 1.3, I'm getting consistent crashes with two glxgear
instances running. So, if you're getting any output, it's better than my
situation.


Before people focuss on software rendering too much -- also with 1.3.0
(and a Matrox Millenium G550 AGP, 32M) glxgears also works decidedly
crummy using hardware rendering. While I can move the glxgears window
itself, the actual spinning wheels stay in the upper-left corner of the
screen and the movement leaves a non-repainting trace on the screen.
Running a second instance of glxgears in addition seems to make both
instances unkillable -- and when I just now forcefully killed X in this
situation (the spinning wheels were covering the upper left corner of all
my desktops) I got the below.

Kernel is 2.6.22.5-cfs-v20.5, schedule() is in the traces (but that may be
expected anyway).

BUG: unable to handle kernel NULL pointer dereference at virtual address 
0010

 printing eip:
c10ff416
*pde = 
Oops:  [#1]
PREEMPT
Modules linked in: nfsd exportfs lockd nfs_acl sunrpc nls_iso8859_1 
nls_cp437 vfat fat nls_base

CPU:0
EIP:0060:[c10ff416]Not tainted VLI
EFLAGS: 00210246   (2.6.22.5-cfs-v20.5-local #5)
EIP is at mga_dma_buffers+0x189/0x2e3
eax:    ebx: efd07200   ecx: 0001   edx: efc32c00
esi:    edi: c12756cc   ebp: dfea44c0   esp: dddaaec0
ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
Process glxgears (pid: 1775, ti=dddaa000 task=e9daca60 task.ti=dddaa000)
Stack: efc32c00  0004 e4c3bd20 c10fa54b e4c3bd20 efc32c00 

   0004     0001 0001 
bfbdb8bc
   bfbdb8b8  c10ff28d 0029 c12756cc dfea44c0 c10f87fc 
bfbdb844

Call Trace:
 [c10fa54b] drm_lock+0x255/0x2de
 [c10ff28d] mga_dma_buffers+0x0/0x2e3
 [c10f87fc] drm_ioctl+0x142/0x18a
 [c1005973] do_IRQ+0x97/0xb0
 [c10f86ba] drm_ioctl+0x0/0x18a
 [c10f86ba] drm_ioctl+0x0/0x18a
 [c105b0d7] do_ioctl+0x87/0x9f
 [c105b32c] vfs_ioctl+0x23d/0x250
 [c11b533e] schedule+0x2d0/0x2e6
 [c105b372] sys_ioctl+0x33/0x4d
 [c1003d1e] syscall_call+0x7/0xb
 ===
Code: 9a 08 03 00 00 8b 73 30 74 14 c7 44 24 04 28 76 1c c1 c7 04 24 49 
51 23 c1 e8 b0 74 f1 ff 8b 83 d8 00 00 00 83 3d 1c 47 30 c1 00 8b 40 
10 8b a8 58 1e 00 00 8b 43 28 8b b8 64 01 00 00 74 32 8b

EIP: [c10ff416] mga_dma_buffers+0x189/0x2e3 SS:ESP 0068:dddaaec0
BUG: unable to handle kernel NULL pointer dereference at virtual address 
0010

 printing eip:
c10ff416
*pde = 
Oops:  [#2]
PREEMPT
Modules linked in: nfsd exportfs lockd nfs_acl sunrpc nls_iso8859_1 
nls_cp437 vfat fat nls_base

CPU:0
EIP:0060:[c10ff416]Not tainted VLI
EFLAGS: 00210246   (2.6.22.5-cfs-v20.5-local #5)
EIP is at mga_dma_buffers+0x189/0x2e3
eax:    ebx: efd07200   ecx: 0001   edx: efc32c00
esi:    edi: c12756cc   ebp: dfea4780   esp: e0552ec0
ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
Process glxgears (pid: 1776, ti=e0552000 task=c19ec000 task.ti=e0552000)
Stack: efc32c00  0003 efc64b40 c10fa54b efc64b40 efc32c00 

   0003     0001 0001 
bf8dbdcc
   bf8dbdc8  c10ff28d 0029 c12756cc dfea4780 c10f87fc 
bf8dbd54

Call Trace:
 [c10fa54b] drm_lock+0x255/0x2de
 [c10ff28d] mga_dma_buffers+0x0/0x2e3
 [c10f87fc] drm_ioctl+0x142/0x18a
 [c11b53f6] preempt_schedule+0x4e/0x5a
 [c10f86ba] drm_ioctl+0x0/0x18a
 [c10f86ba] drm_ioctl+0x0/0x18a
 [c105b0d7] do_ioctl+0x87/0x9f
 [c105b32c] vfs_ioctl+0x23d/0x250
 [c11b52a9] schedule+0x23b/0x2e6
 [c11b533e] schedule+0x2d0/0x2e6
 [c105b372] sys_ioctl+0x33/0x4d
 [c1003d1e] syscall_call+0x7/0xb
 ===
Code: 9a 08 03 00 00 8b 73 30 74 14 c7 44 24 04 28 76 1c c1 c7 04 24 49 
51 23 c1 e8 b0 74 f1 ff 8b 83 d8 00 00 00 83 3d 1c 47 30 c1 00 8b 40 
10 8b a8 58 1e 00 00 8b 43 28 8b b8 64 01 00 00 74 32 8b

EIP: [c10ff416] mga_dma_buffers+0x189/0x2e3 SS:ESP 0068:e0552ec0
[drm:drm_release] *ERROR* Device busy: 2 0


Rene.
-
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: CFS review

[Rene Herman]

On 08/30/2007 06:06 PM, Chuck Ebbert wrote:


On 08/29/2007 03:56 PM, Rene Herman wrote:



Before people focuss on software rendering too much -- also with 1.3.0
(and a Matrox Millenium G550 AGP, 32M) glxgears also works decidedly
crummy using hardware rendering. While I can move the glxgears window
itself, the actual spinning wheels stay in the upper-left corner of the
screen and the movement leaves a non-repainting trace on the screen.
Running a second instance of glxgears in addition seems to make both
instances unkillable -- and when I just now forcefully killed X in this
situation (the spinning wheels were covering the upper left corner of
all my desktops) I got the below.

Kernel is 2.6.22.5-cfs-v20.5, schedule() is in the traces (but that may
be expected anyway).



And this doesn't happen at all with the stock scheduler? (Just confirming,
in case you didn't compare.)


I didn't compare -- it no doubt will. I know the title of this thread is 
CFS review but it turned into Keith Packard noticing glxgears being broken 
on recent-ish X.org. The start of the thread was about things being broken 
using _software_ rendering though, so I thought it might be useful to 
remark/report glxgears also being quite broken using hardware rendering on 
my setup at least.



BUG: unable to handle kernel NULL pointer dereference at virtual address
0010
 printing eip:
c10ff416
*pde = 
Oops:  [#1]
PREEMPT


Try it without preempt?


If you're asking in a I'll go debug the DRM way I'll go dig a bit later 
(please say) but if you are only interested in the thread due to CFS, note 
that I'm aware it's not likely to have anything to do with CFS.


It's not reproducable for you? (full description of bug above).

Rene.
-
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 with IDE on linux 2.6.22.X

[Rene Herman]

On 08/30/2007 09:31 PM, Jan Engelhardt wrote:


On Aug 28 2007 19:05, Rene Herman wrote:



Sheesh. How could anyone _not_ understand you need SCSI CD-ROM support
for your IDE DVD-RW drive...


Welcome to the wonderful world of SCSIfying ATA. (Don't talk about ATAPI,
USB/Firewire, it's a different matter.)


Well -- the world where ATA, SCSI, USB, Firewire and what have you are 
low-level drivers to a unifying storage layer is under non too obscure 
definitions sort of not non-wonderful...


Admittedly, the unifying layer is a little SCSI inspired but so is a lot of 
the hardware. As long as the users (the humans) resist SCSI inspiration, it 
should be safe.


Rene
-
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 with IDE on linux 2.6.22.X

[Rene Herman]

On 08/30/2007 11:16 PM, Greg Freemyer wrote:


On 8/30/07, Rene Herman [EMAIL PROTECTED] wrote:



Well -- the world where ATA, SCSI, USB, Firewire and what have you are
low-level drivers to a unifying storage layer is under non too obscure
definitions sort of not non-wonderful...



USB / Firewire / FC / iSCSI are all SCSI transports and fit within the
SCSI subsystem by design.

ie. Just like ethernet, DSL, T-1, etc can all carry IP traffic with no
conceptual conflict, many media by design carry SCSI traffic.

The PATA and SATA physical layer typically carry ATA commands and
having them tied into the SCSI stack is an aberration that I hope will
be eliminated some day.

ATAPI is an exception.  Not sure where that would end up in a perfect world.


As said, if you make a bit of an effort to view the former SCSI stack as a 
unified storage midlayer the abberation becomes less abberational (if that's 
a word).


Real SCSI, the other SCSI transports and ATAPI would just use more of the 
common mid-layer than P/SATA would. I'd expect the way forward would be to 
just refactor things until someone notices that drivers/scsi is the wrong 
place for sd.c and sr.c and moves them to drivers/block or whereever.


Practically, the PATA driver gives me (almost) the same throughput as the 
old IDE driver does, and given that I need the former SCSI stack _anyway_ 
for my external USB harddrive, I don't see a pressing need to carry along 
yet another storage stack for my harddrive.


Rene.


-
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/

DRM and/or X trouble (was Re: CFS review)

[Rene Herman]

On 08/31/2007 08:46 AM, Tilman Sauerbeck wrote:


On 08/29/2007 09:56 PM, Rene Herman wrote:



With X server 1.3, I'm getting consistent crashes with two glxgear
instances running. So, if you're getting any output, it's better than my
situation.

Before people focuss on software rendering too much -- also with 1.3.0
(and a Matrox Millenium G550 AGP, 32M) glxgears also works decidedly
crummy using hardware rendering. While I can move the glxgears window
itself, the actual spinning wheels stay in the upper-left corner of the
screen and the movement leaves a non-repainting trace on the screen.


This sounds like you're running an older version of Mesa.
The bugfix went into Mesa 6.3 and 7.0.


I have Mesa 6.5.2 it seems (slackware-12.0 standard):

OpenGL renderer string: Mesa DRI G400 20061030 AGP 2x x86/MMX+/3DNow!+/SSE
OpenGL version string: 1.2 Mesa 6.5.2

The bit of the problem sketched above -- the gears just sitting there in the 
upper left corner of the screen and not moving alongside their window is 
fully reproduceable. The bit below ... :



Running a second instance of glxgears in addition seems to make both
instances unkillable -- and when I just now forcefully killed X in this
situation (the spinning wheels were covering the upper left corner of all
my desktops) I got the below.


[ two kernel BUGs ]

... isn't. This seems to (again) have been a race of sorts that I hit by 
accident since I haven't reproduced yet. Had the same type of racyness 
trouble with keyboard behaviour in this version of X earlier.



Running two instances of glxgears and killing them works for me, too.

I'm using xorg-server 1.3.0.0, Mesa 7.0.1 with the latest DRM bits from
http://gitweb.freedesktop.org/?p=mesa/drm.git;a=summary


For me, everything standard slackware-12.0 (X.org 1.3.0) and kernel 2.6.22 DRM.


I'm not running CFS though, but I guess the oops wasn't related to that.


I've noticed before the Matrox driver seems to get little attention/testing 
so maybe that's just it. A G550 is ofcourse in graphics-time a Model T by 
now. I'm rather decidedly not a graphics person so I don't care a lot but 
every time I try to do something fashionable (run Google Earth for example) 
I notice things are horribly, horribly broken.


X bugs I do not find very interesting (there's just too many) and the kernel 
bugs are requiring more time to reproduce than I have available. If the BUGs 
as posted aren't enough for a diagnosis, please consider the report withdrawn.


Rene.

-
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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

[Rene Herman]

On 08/13/2007 09:16 AM, Al Viro wrote:


On Sun, Aug 12, 2007 at 10:49:34PM -0700, Joe Perches wrote:

I grew weary of looking up the appropriate
maintainer email address(es) to CC: for a patch.


Does the acronym GAFL ring any bells?  It's not that idea is worthless -
it sure as hell is a useful thing, but what the bleeding hell is that
splitup supposed to achieve?


Well, to be fair, he's CCing the addresses in the individual entries which 
is at least somewhat of a reason. Yes, could've worked via preparation via 
private mail as well or something but hey, posting some 600 patches is at 
least incredibly funny :-)


Only thing left now is to now teach Linus's copy of git about these entries 
so that it doesn't turn into an wholy incomplete, obsolete mess through 
addition, removal and movement of files in a few months time...


Rene.
-
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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

[Rene Herman]

On 08/13/2007 07:42 PM, Arjan van de Ven wrote:


On Mon, 2007-08-13 at 19:33 +0200, Mariusz Kozlowski wrote:

Hello,

I don't recall discusion about this so here are my 3 cents:

	I like the idea. 


I don't actually. It shows a central MAINTAINERS file is the wrong
approach; just that 500+ patches to the same file were needed shows
that. 


Quite.

The maintainer info should be in the source file itself! That's the only 
reasonable way to keep it updated; now I'm all for having it machine 
parsable so that tools can use it, but it still really should be in the 
code itself, not in some central file that will always just go out of 
data, and will be a huge source of needless patch conflicts.


This is quite like the OO-INDEX discussion now going, where I saw it argued 
that the one-line summaries could go at the top of the actual Documentation 
files themselves, where they could be mechanically extracted to _build_ the 
index files. Keeping things in sync is the important reason there as well.


While the notion behing these patches appears to be good, the tree sees many 
changes through addition, removal and movement of files which affects this. 
Is Linus's copy of git going to check if an added file doesn't overlap with 
an existing wildcard in the MAINTAINERS file and delele or adjust wildcards 
upon removal or movement?


I personally think it wouldn't be such as bad idea to introduce a standard 
Linux source file header, with (when present) information such as the 
summary for index files, maintainer information, and other information now 
present in MAINTAINERS. With it being in the sourcefile themslves, it will 
stand a much better chance of staying up to date.


Rene.
-
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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

[Rene Herman]

On 08/14/2007 03:19 AM, Arjan van de Ven wrote:


On Mon, 2007-08-13 at 16:37 -0400, Trond Myklebust wrote:

On Mon, 2007-08-13 at 10:42 -0700, Arjan van de Ven wrote:



The maintainer info should be in the source file itself! That's the only
reasonable way to keep it updated; now I'm all for having it machine
parsable so that tools can use it, but it still really should be in the
code itself, not in some central file that will always just go out of
data, and will be a huge source of needless patch conflicts.


If the problem is to do with people failing to update the MAINTAINERS 
file, why would moving the same data into 20 or 30 source files

motivate them to keep it up to date? As far as I can see, that would
just serve to multiply the amount of stale data...


if each .c file has a MODULE_MAINTAINER() tag... 


people tend to update .c files a lot better than way off-the-side other
files.


MODULE_MAINTAINER() was discussed a while ago but embedding information into 
the binary has the problem you can't ever change deployed systems, meaning 
it lags by design. If a maintainer changes, people would still be using the 
information from their old binaries, meaning a replaced maintainer might get 
contacted for potentially years still (and the new one not).


(you could avoid that by placing not a name/address in the maintainer tag 
but a pointer to somewhere else but at that point this gets to be about 
solving something else).


Keeping it in the source alone is fine. C files could just embed their 
MAINTAINERS entry as a header:


/*
 * P: Maintainer
 * M: Mail patches to
 * L: Mailing list that is relevant to this area
 * W: Web-page with status/info
 * T: SCM tree type and location.  Type is one of: git, hg, quilt.
 * S: Status, one of the following:
 */

And probably adding fields:

 * I: Info/Summary (for index files and the like)
 * A: Author
 * G: License

and such. Yes, while we're at it, we can pick better letters or full word 
tags ;-)


Rene.

-
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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

[Rene Herman]

On 08/14/2007 03:51 AM, Rene Herman wrote:

MODULE_MAINTAINER() was discussed a while ago but embedding information 
into the binary has the problem you can't ever change deployed systems, 
meaning it lags by design. If a maintainer changes, people would still 
be using the information from their old binaries, meaning a replaced 
maintainer might get contacted for potentially years still (and the new 
one not).


(you could avoid that by placing not a name/address in the maintainer 
tag but a pointer to somewhere else but at that point this gets to be 
about solving something else).


Keeping it in the source alone is fine. C files could just embed their 
MAINTAINERS entry as a header:


/*
 * P: Maintainer
 * M: Mail patches to
 * L: Mailing list that is relevant to this area
 * W: Web-page with status/info
 * T: SCM tree type and location.  Type is one of: git, hg, quilt.
 * S: Status, one of the following:
 */

And probably adding fields:

 * I: Info/Summary (for index files and the like)
 * A: Author
 * G: License

and such. Yes, while we're at it, we can pick better letters or full 
word tags ;-)


Okay, and if a single maintenance unit consists of many files, this gets 
to be too much yes. But they _could_ just grow a header pointing back to the 
MINTAINERS file/database;


/*
 * MAINTAINERS: 3C359 NETWORK DRIVER
 */

Thst should keep things minimal enough to keep them updated, no?

Rene.
-
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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

[Rene Herman]

On 08/14/2007 11:20 AM, Alan Cox wrote:

MODULE_MAINTAINER() was discussed a while ago but embedding information into 
the binary has the problem you can't ever change deployed systems, meaning 
it lags by design. If a maintainer changes, people would still be using the 
information from their old binaries, meaning a replaced maintainer might get 
contacted for potentially years still (and the new one not).


And as was pointed out at the time, the people whining about that were
talking out of the wrong equipment. The supplier of the code can no more
or less easily change the binary as the matching source tree once its been
shipped. In fact its probably easier to change the binaries as the
sources will be left on CD.


That's just not a complete argument if one accepts that users can be people 
without _any_ source tree lying around. There's no reason this user would 
believe that any source tree, matching or not, would provide him with beter 
information than the information modinfo just spat at him. The only thing 
that helps is not have modinfo spit _any_ contact information at him so he 
knows to look elsewhere.


And even more importantly ...

PUHLEASE PUHLEASE don't dirty this discussion with binary tags in the first 
place! It isn't about MODULE_FOO() tags, it is about tagging /source/ files 
to help with putting CCs on patch submissals. People who submit patches sort 
of by definition have a current source tree lying around, and do not need to 
grab information from any binaries. As such, putting it in a comment inside 
the source is all that's relevant here, not anything to do with binaries.


So, let's talk source. If we want to link source file foo.c and the 
MAINTAINERS information, we have 3 options:


1. MAINTAINERS -- foo.c

This is what Joe Perches' current 550 piece proposal does. Although I can 
hardly wait for version 2 of the patchset, high potential to turn into an 
incomplete obsolete mess upon adding, removing and moving files around.


2. foo.c -- MAINTAINERS

Putting a copy of the MAINTAINERS entry in a header in a every single source 
file (Joe already nicely provided us with the paths to script something like 
that) works but considering that single maintenance units might consist of 
many source files, people might not bother to keep them all updated and in 
sync and really, they shouldn't need to.


Sticking a single backlink to a MAINTAINERS file entry at the top of a 
source file might work:


--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ ... @@
+/*
+ * MAINTAINERS: IDE/ATAPI CDROM DRIVER
+ */

[ ... ]

3. foo.c -- some 3rd file -- MAINTAINERS

Just for completeness and trying to make sure I'm not inventing an or/or but 
I don't see any use in this linkage, so it's 1 or 2 it seems.


Note, perhaps after we have a MAINTAINERS source tag, we can discuss whether 
or not it could in fact be a MODULE_MAINTAINER() binary tag, but that's then 
about something else at that point...


Rene.

-
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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

[Rene Herman]

On 08/14/2007 07:00 PM, Joe Perches wrote:


On Tue, 2007-08-14 at 17:53 +0200, Rene Herman wrote:


It isn't about MODULE_FOO() tags, it is about tagging /source/ files 
to help with putting CCs on patch submissals.
If we want to link source file foo.c and the 
MAINTAINERS information, we have 3 options:

1. MAINTAINERS -- foo.c
2. foo.c -- MAINTAINERS
3. foo.c -- some 3rd file -- MAINTAINERS


I added [EMAIL PROTECTED] and Junio Hamano


Well, yes, I agree -- going through GIT seems to be the only really workable 
solution.


That is, instead of (case 2, you snipped it) having a backlink to the 
MAINTAINERS file in a header inside the source GIT would maintain this 
backlink -- and at that point, you can basically forego the MAINTAINERS file 
completely other than as something GIT can generate and just regard all of 
it meta-information (you may want to generate MAINTAINERS for releases but 
making GIT the source is the idea).


git info --maintainer drivers/ide/ide-cd.c or some such would say Alan 
Cox [EMAIL PROTECTED].


There are more possibilities for this kind of meta information. git info 
--author, git info --license, git info --whatever. Given that it's intended 
for developers, needing GIT should not get in the way but there's always the 
generated MAINTAINERS file in releases as well.


It would ofcourse automatically stay up to date through deleting and moving 
of files. You'd probably want to devise a way to enable a submitter to also 
automatically provide meta-information upon addition of files. This can be 
done in the same way as a Signed-off-by. Just tags in a submit email.


This should probably turn out to be the way things work yes. The paths in 
the MAINTAINERS file grow stale, source headers might also and sticking 
headers on every source file isn't nice anyway -- it's meta-information and 
the SCM can maintain it.


Rene.
-
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] [443/2many] MAINTAINERS - HIBERNATION (aka Software Suspend, aka swsusp):

[Rene Herman]

On 08/14/2007 08:15 PM, Linus Torvalds wrote:

Quite frankly, I think the MAINTAINERS file gets a whole lot uglier this 
way.


There's also a rather fundamental issue: this will likely make people 
touch the MAINTAINERS file *more*, and from a maintenance standpoint, that 
is exactly the wrong thing to have (one central file that everybody 
touches). It just tends to generate unnecessary merge conflicts etc. 

(We used to have that issue with the central configuration file, for 
example).


So the more I look at these things, the more convinced I am that this is 
not the right thing to do. These things should *not* be in one huge file, 
and I'd much much rather have the maintainership information be carried 
along with the subsystem itself, or the files it contains.


In other words, it would be much better to just have per-file markers, 
along with some per-subdirectory stuff or similar.


Joe just now convinced me that rather than the per-file markers, the marker 
is meta-information that could just be stored in GIT, with the MAINTAINERS 
file turning into something generated.


git info --maintainer and such (for many possible kinds of --flags) would 
throw out the information.


Rene.
-
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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

[Rene Herman]

On 08/14/2007 08:28 PM, Joe Perches wrote:


On Tue, 2007-08-14 at 20:03 +0200, Rene Herman wrote:
git info --maintainer drivers/ide/ide-cd.c or some such would say Alan 
Cox [EMAIL PROTECTED].


Perhaps maintainer(s), approver(s), listener(s)?

I think something like this should be a git-goal.
What do the git-wranglers think?


I agree. If this thing has source management, let's use it.


Until a time in the future when a system like that exists,
I suggest keeping MAINTAINERS up-to-date with

F:  pattern

It'll be useful as git-set-maintainer seeds at least.


Yes. Seeing as how it's already been useful in updating the information it 
would be a shame to throw what you already did away. Don't underestimate how 
fast git-wranglers can implement stuff if they agree though... :-)



sticking  headers on every source file isn't nice anyway --
it's meta-information and the SCM can maintain it.


It's like looking at $CVS$ keywords.  Unsightly.


Again agree.

Rene.


-
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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

[Rene Herman]

On 08/14/2007 09:33 PM, Al Viro wrote:


FWIW, I suspect that we are looking at that from the wrong POV.  If
that's about who ought to be Cc'd on the issues dealing with list
of pathnames, why does it have to be tied to who is maintainer for
pathname?

I'm not suggesting something like [EMAIL PROTECTED] with something
like majordomo allowing to add yourself to those, but something less
extreme in that direction might be worth thinking about...  Hell,
even simple
$ finger fs/minix/[EMAIL PROTECTED]
with majordomo-like interface for adding yourself to such lists
might solve most of those problems...


It mostly is just about that it seems. However, this would not also allow 
the other information currently in the MAINTAINERS file to be queried in 
similar ways.


Git could grow a generic file meta data implementation through the use of 
tags, sort of like tags on multimedia files although while with multimedia 
files the tags are in fact stored as a file header, here you'd keep them 
just in git. Any project using git would be free to define its own set of 
info tags and you'd supply them to git simply as a list of


tag=value

pairs:

$ git info --add drivers/ide/ide-cd.c EOF
CC=Alan Cox [EMAIL PROTECTED], [EMAIL PROTECTED]
EOF

Or as a more expansive example, with the tags set on a directory (and the 
output shown this time):


$ git info drivers/infiniband/
CC=Roland Dreier [EMAIL PROTECTED]
CC=Sean Hefty [EMAIL PROTECTED]
CC=Hal Rosenstock [EMAIL PROTECTED]
[EMAIL PROTECTED]
W=http://www.openib.org/
T=git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git

$ git info --type=W drivers/infiniband/
http://www.openib.org/

The project can link the actual tags such as CC, W and T to --options for 
the info command in the git configuration file for the tree (and/or just 
define a few upfront I guess) making it look nicer:


$ git info --cc drivers/infiniband/
Roland Dreier [EMAIL PROTECTED]
Sean Hefty [EMAIL PROTECTED]
Hal Rosenstock [EMAIL PROTECTED]
[EMAIL PROTECTED]

$ git info --website drivers/infiniband/
http://www.openib.org/

$ git info --tree drivers/infiniband/
git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git

Extra: when you have such an implementation, you can use it for other 
purposes as well such as the summary Documentation/ files want for the 
00-INDEX files:


$ git info --summary Documentation/BUG-HUNTING
brute force method of doing binary search of patches to find bug.

And importantly -- when queuried for a file that itself doesn't have the 
requested info tag:


$ git info --cc drivers/infiniband/core/addr.c

git looks for the tag on the drivers/infiniband/core/ directory next, and 
then on drivers/infiniband/, where it finds it. linux-kernel@vger.kernel.org 
would be the final fallback, being set on the project root.


I'd really like something like this. As long as projects are both free to 
use and not use them and free to define their own set of tags I believe this 
would work very nicely.


Once you have these tags, you can basically use them for anything.

Rene.

-
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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

[Rene Herman]

On 08/15/2007 07:25 AM, Junio C Hamano wrote:


Joe Perches [EMAIL PROTECTED] writes:



Rene Herman had an idea about using some git
metadata that might be useful.  The completely
external data approach suggested by Al Viro 
might be OK too in that it wouldn't tie listeners

to git requiring more content in git metadata.


The reason I found Linus's suggestion desirable is because it
fundamentally does not require git to track any metadata.  If
the commits are in git, then his script would let you gather the
data, but otherwise you should be able to do the same by
grepping patches.  Obviously you would need to filter by paths,
looking at the diffstat, but the approach does _not_ tie users
to git.


I believe that wouldn't be much of a problem really. Users in this context 
are people submitting patches and most people who do will, could and maybe 
even should be running git these days -- git is very good, GPLd and the 
Linux source code managament system.


But for occasional contributors that don't, a MAINTAINERS file much like the 
current could also be generated into releases; it's just that the source 
would live as file/directory metadata inside git.


Still like the notion of a generic file/directory metadata implementation 
inside git, through that tag=value system that I suggested. Wouldn't 
be intrinsically tied to Linux or anything, with any project being free to 
invent their own tags and has heaps of possible uses, from the current 
MAINTAINERS info, through summary information, author/licese information, 
anything goes...


Rene.
-
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: kfree(0) - ok?

[Rene Herman]

On 08/15/2007 09:28 AM, Jan Engelhardt wrote:


On Aug 14 2007 16:21, Jason Uhlenkott wrote:



On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:

NULL is not 0 though.

It is.  Its representation isn't guaranteed to be all-bits-zero,


C guarantees that.


C guarantees what? If you're disagreeing with Jason -- he's right.


but the constant value 0 when used in pointer context is always a
null pointer (and in fact the standard requires that NULL be
#defined as 0 or a cast thereof).


Rene.
-
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: kfree(0) - ok?

[Rene Herman]

On 08/15/2007 11:20 AM, Jan Engelhardt wrote:


On Aug 15 2007 10:37, Rene Herman wrote:

On 08/15/2007 09:28 AM, Jan Engelhardt wrote:

On Aug 14 2007 16:21, Jason Uhlenkott wrote:

On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:



NULL is not 0 though.


It is.  Its representation isn't guaranteed to be all-bits-zero,


C guarantees that.


C guarantees what? If you're disagreeing with Jason -- he's right.


http://coding.derkeiler.com/Archive/C_CPP/comp.lang.c/2003-11/1808.html


He said the null _pointer_ isn't guaranteed to be all-bits zero. And it 
isn't. Read the standard or the faq.



but the constant value 0 when used in pointer context is always a
null pointer (and in fact the standard requires that NULL be
#defined as 0 or a cast thereof).


Rene.
-
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: kfree(0) - ok?

[Rene Herman]

On 08/15/2007 12:20 PM, Jan Engelhardt wrote:


On Aug 15 2007 11:58, Rene Herman wrote:

NULL is not 0 though.

It is.  Its representation isn't guaranteed to be all-bits-zero,



He said the null _pointer_ isn't guaranteed to be all-bits zero. And it
isn't. Read the standard or the faq.


0 is all-bits-zero.
NULL is 0. (It is., above)


NULL is a define. It does not have a binary presentation. He was talking 
about the representation of the null pointer, not of 0.


Retarded language lawyering over in comp.lang.c please where all the other 
people who think they just have to be brilliant for having been able to read 
a standards documents go to wank off.


Rene.
-
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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

[Rene Herman]

On 08/15/2007 11:39 AM, Stefan Richter wrote:


Note, maintainer contacts
  - should be available to patch submitters and
  - must be available to *problem reporters*
without having to have git and a .git repo.


That must seems rather strong. But those few non-developer users that 
could care are served by a MAINTAINERS file generated into releases.


Rene.
-
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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

[Rene Herman]

On 08/15/2007 03:33 PM, Satyam Sharma wrote:

[ git info --maintainer ]


I'd really _love_ a tool that does all that what you've proposed above!

But why does it have to be git-info or anything in the git(7) suite for
that matter? This sounds like a job for a different specialised tool, 
along with .metatags kind of files dispersed in the source tree.


To automatically move (and delete) the meta-data alongside the files 
themselves is a reason.


More generally -- shouldn't it? This is about source management (well, maybe 
more about project management, but...) and the source code management tool 
looks to be the right place for that. The different parts of git are 
somewhat/fairly stand-alone as is, no?


Rene.
-
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: do get_rtc_time() correctly

[Rene Herman]

On 08/16/2007 02:26 AM, David P. Reed wrote:


My mention of NMI (which by definition can't be masked) is because NMI


Well, not by the CPU it can't, but on a PC, masking NMIs is a simple matter 
of setting bit 7 of I/O port 0x70 to 1 (it seems the kernel does not provide 
an interface for it though?).


Rene.

-
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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

[Rene Herman]

On 08/15/2007 03:52 PM, Kyle Moffett wrote:


On Aug 15, 2007, at 09:39:44, Rene Herman wrote:

On 08/15/2007 03:33 PM, Satyam Sharma wrote:

[ git info --maintainer ]

I'd really _love_ a tool that does all that what you've proposed 
above!  But why does it have to be git-info or anything in the 
git(7) suite for that matter? This sounds like a job for a different 
specialised tool,  long with .metatags kind of files dispersed in 
the source tree.


To automatically move (and delete) the meta-data alongside the files 
themselves is a reason.


More generally -- shouldn't it? This is about source management (well, 
maybe more about project management, but...) and the source code 
management tool looks to be the right place for that. The different 
parts of git are somewhat/fairly stand-alone as is, no?


If you were going to do that I'd just suggest making git aware of the 
user.* extended attributes and having it save those into the git repo 
along with the permission data.


Am looking at it but am not so sure that's a very good idea. I guess it'd be 
largely okay-ish to require the repo to be on a filesystem that supports EAs 
for this feature to work, but keeping the attributes intact over file system 
operations seems not all that easy (yet). Having not used EAs before I may 
be missing something but my version of cp for example (GNU coreutils 6.9) 
appears to not copy them. Nor do they seem to survive a trip through GNU tar 
1.16.1. EAs appear to not be very useful unless every single tool supports 
them -- a repo should be resistant against simple operations like that.


Googling around, I see subversion already has this and calls the meta-data 
properties (svn propset/get and friends). It uses a few properties itself, 
such as the svn:executable property (which I saw is also the only permission 
bit git keeps) and svn:ignore, which serves the same role as the .gitignore 
files for git. Both those would fit into this scheme nicely for git as well, 
if git were to do something similar and reserve for example the git.* 
namespace for internal use.


Junio (and others), do you have an opinion on this? If these properties are 
versioned themselves such as in svn I believe it's a decidedly non-trivial 
addition (and I'm a complete git newbie) but to me, they look incredibly 
useful, both for the original maintainers properties (and anyone else one 
would want to come up with such as summary properties and author/license 
stuff) and even for git internal reasons such as sketched above.


The git-blame thing as sketched before by Linus would never be able to point 
out mailing lists, or general lists of interested parties for example, but 
these properties can do anything...


Rene.
-
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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

[Rene Herman]

On 08/16/2007 12:58 PM, Rene Herman wrote:


On 08/15/2007 03:52 PM, Kyle Moffett wrote:


If you were going to do that I'd just suggest making git aware of the 
user.* extended attributes and having it save those into the git 
repo along with the permission data.


Am looking at it but am not so sure that's a very good idea. I guess 
it'd be largely okay-ish to require the repo to be on a filesystem that 
supports EAs for this feature to work, but keeping the attributes intact 
over file system operations seems not all that easy (yet). Having not 
used EAs before I may be missing something but my version of cp for 
example (GNU coreutils 6.9) appears to not copy them. Nor do they seem 
to survive a trip through GNU tar 1.16.1. EAs appear to not be very 
useful unless every single tool supports them -- a repo should be 
resistant against simple operations like that.


Googling around, I see subversion already has this and calls the 
meta-data properties (svn propset/get and friends). It uses a few 
properties itself, such as the svn:executable property (which I saw is 
also the only permission bit git keeps) and svn:ignore, which serves the 
same role as the .gitignore files for git. Both those would fit into 
this scheme nicely for git as well, if git were to do something similar 
and reserve for example the git.* namespace for internal use.


Junio (and others), do you have an opinion on this? If these properties 
are versioned themselves such as in svn I believe it's a decidedly 
non-trivial addition (and I'm a complete git newbie) but to me, they 
look incredibly useful, both for the original maintainers properties 
(and anyone else one would want to come up with such as summary 
properties and author/license stuff) and even for git internal reasons 
such as sketched above.


The git-blame thing as sketched before by Linus would never be able to 
point out mailing lists, or general lists of interested parties for 
example, but these properties can do anything...


The svn implemention is that a single property is free-form text. As such, I 
guess a property would be just another file, although one that only lives in 
the index and is linked from the file/directory it is a property of.


Perhaps that immediately suggests an implementation to someone already 
familiar with git internals?


Rene.

-
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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

[Rene Herman]

On 08/16/2007 01:26 PM, Salikh Zakirov wrote:

Please don't drop CCs.


Rene Herman wrote:

Perhaps that immediately suggests an implementation to someone already
familiar with git internals?


perhaps http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
and http://www.kernel.org/pub/software/scm/git/docs/git-check-attr.html
can help you?


No, thanks, saw them, but .gitattributes is in fact in the same category as 
.gitignore, which would _be_ a property.


If you do this stuff in files scattered around the tree, updating and moving 
stuff becomes a pain -- the tool would need to go edit files.


Rene.



-
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: Storing Maintainers info around the kernel tree

[Rene Herman]

On 08/16/2007 03:04 PM, Kyle Moffett wrote:


On Aug 16, 2007, at 07:57:23, Rene Herman wrote:



category as .gitignore, which would _be_ a property.

If you do this stuff in files scattered around the tree, updating and 
moving stuff becomes a pain -- the tool would need to go edit files.


From a practical standpoint we don't want to duplicate someone's 
maintainer information in the attributes of every file they maintain.  


In a tree structure, you don't have to. As described earlier, the tool 
(git-prop) looks for the requested property being set first on the file 
itself, then on the directory in which it resides, then its parent, and so 
on. If I read things right, this is also how properties work in subversion 
in fact.


So after

$ git prop --set --name maintainer --value \
Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] drivers/ide/
and

$ git prop --set --name maintainer --value \
Alan Cox [EMAIL PROTECTED] drivers/ide/ide-cd.*

we get:

$ git prop --get --name maintainer drivers/ide/ide-cd.c
Alan Cox [EMAIL PROTECTED]

$ git prop --get --name maintainer drivers/ide/ide-generic.c
Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]

Now, this override behaviour needs a tree structure ofcourse, but notice I 
set the maintainer property only to the name/address. The other 
information from the MAINTAINERS file would be using their own properties:


$ git prop --set --name tree --value \
quilt kernel.org/pub/linux/kernel/people/bart/pata-2.6/ drivers/ide/

and nothing under drivers/ide/ would override this value nor would it be 
repeated anywhere. Alan takes care of more than ide-cd but only the actual 
maintainer value string would be set on the others as well and repeating 
that much for different maintenance units is no different from the current 
MAINTAINERS file where it also is (well, would be, Alan is in fact only 
listed for ide-cd it seems...) repeated in different entries.


(as a slight difference -- in the above example, Alan's information _is_ 
repeated over ide-cd.c and ide-cd.h where the current MAINTAINERS file just 
says IDE/ATAPI CDROM DRIVER, but that's a bit of an oddbal situation since 
you normally have either single files or a tree that make up a maintenance 
unit -- and is in fact just a human versus tool difference).


It would be much easier to put in the kernel/somesubsys directory a 
Maintainers file which has:


It's ofcourse possible, but note that if we want this stuff to be minimally 
manual, moving files around (and deleting them) then requires editing these 
actual in-tree files via a tool.


With the properties deleting files just requires deleting any file-specific 
properties alongside which is trivial since those are linked from the file.


Moving stuff works by building a list of all properties that are set on the 
source starting at the source and destination's highest shared parent 
directory and then reconstructing this list at the destination, striking 
properties off the list that are already set at the destination.


Adding properties, alongside added files or after the fact, could be done 
via standard patch submissals via the kind of meta-diff that already 
exists for git move.


I really believe this stuff should be meta-data -- and these properties as 
outlined work well it seems.


$ git prop --set --name git.ignore -V ./.gitignore .
$ rm .gitignore

This is something I saw subversion also uses properties for. Takes the value 
from a file instead of the command line. .gitattributes are also easily 
incorporated into the property-system directly.


$ git prop --set --name git.executable scripts/Lindent

Must say I'm not particularly sure if this one has much value over the 
current executable bit storage,but also from svn and example of a boolean 
property.


$ git prop --set --name license --value GPL v2 .
$ git prop --set --name license --value GPL sound/alsa/

and so on. The GPL v2 on the source root only works if you set the property 
on everything that's not, so you may not want to but as a wouldn't it be 
nice if kinda thing. Makes for easy license analysis at least...


$ git prop --set --name FIXME drivers/block/floppy.c

Okay, that's probably overdoing it a bit, but as long as I'm having fun here...

Note -- the properties would be versioned themselves ofcourse so that you'd 
always have a tree where data and meta-data matched. Basically, I believe 
you'd view the properties as just more data files, one per property, with 
the exception that they'd not actually live in the working tree and are 
linked from data (files/directories) that do.


Long letters of intent this, but I'm by now in love with these things. 
More comments (or implementations obviously :-) welcome. Any significant 
misses in this?


Rene.

-
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

Re: [linux-pm] Re: Storing Maintainers info around the kernel tree

[Rene Herman]

On 08/16/2007 05:31 PM, Alan Stern wrote:

Please remember that not everybody uses git.  The MAINTAINERS data 
should be available in the kernel source itself.


It may be useful to generate a MAINTAINERS file into releases yes.

I must say though that why? would also be a question. I personally don't 
think there's a whole lot wrong with more and more expecting people who 
submit patches (for whom this automation is intended) to be using git. Back 
in the BK days there were lots of reasons for resisting any and all 
dependency on the source code management tool but there don't seem to be too 
many left today as far as I'm concerned.


If it's about non-developer users, I suspect it would to a fairly large 
degree be an in theory thing to expect that said user does want the 
information in a downloaded releases, but not in git, and not online where 
git-web could also easily display all the information right alongside the files.


But yes, sure, anything can be generated...

Rene.
-
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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

[Rene Herman]

On 08/16/2007 05:40 PM, Al Viro wrote:


On Thu, Aug 16, 2007 at 12:58:19PM +0200, Rene Herman wrote:


The git-blame thing as sketched before by Linus would never be able to 
point out mailing lists, or general lists of interested parties for 
example, but these properties can do anything...


No, they can not.  I'm interested in drivers/foo/bar.c fixes is not
an earth-shattering event and it sure as hell does not create a new revision
of the tree.


That's true. Okay, it can't do those general lists of interested parties.

Rene.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm] Re: Storing Maintainers info around the kernel tree

[Rene Herman]

On 08/16/2007 11:39 PM, Stefan Richter wrote:

Rene Herman wrote:



I personally don't think there's a whole lot wrong with more and more
expecting people who submit patches (for whom this automation is
intended) to be using git.


You mean people who frequently submit patches for various different
subsystems.


Erm, I guess. Is that agreeing or disagreeing with me?

Rene.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm] Re: Storing Maintainers info around the kernel tree

[Rene Herman]

On 08/17/2007 03:58 AM, Alan Stern wrote:


On Fri, 17 Aug 2007, Rene Herman wrote:


On 08/16/2007 11:39 PM, Stefan Richter wrote:

Rene Herman wrote:


I personally don't think there's a whole lot wrong with more and 
more expecting people who submit patches (for whom this automation 
is intended) to be using git.


You mean people who frequently submit patches for various different
subsystems.


Erm, I guess. Is that agreeing or disagreeing with me?


Don't forget also that the MAINTAINERS information is (or should be!)
used by people who want to submit bug reports, not just by people who
submit patches.  Bug reporters shouldn't need to use Git.


Like I said:


If it's about non-developer users, I suspect it would to a fairly large
degree be an in theory thing to expect that said user does want the
information in a downloaded releases, but not in git, and not online 
where git-web could also easily display all the information right 
alongside the files.


And again, generating the MAINTAINERS file/info into releases is fine as well.

Rene.
-
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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

[Rene Herman]

On 08/16/2007 09:00 PM, Junio C Hamano wrote:


Git or no git, I think a file that can be viewed with less,
edited with regular editor and processed with sed/perl/grep
tools is the way to go.  I do not think adding 600+ patches to
the single MAINTAINERS list is workable in the longer term, as
it would become the single file many subsystem people need to
update and is asking for merge conflicts, but I think a file
with known name (say, CcMe.txt) sprinkled in relevant
subdirectories, perhaps with the same format originally
suggested for MAINTAINERS, would make a lot more sense.

That would give people who work with tarballs and patches, or a
subsystem managed with something other than git (one of the most
important one is quilt), the equal access to the necessary data.


That is ofcourse an argument but I believe a bit of a non-argument at the 
same time in practice.


There's really not much point in pretending that non-git users are still 
first class citizens anyway; Linus' own suggestion of using git-blame would 
tie things to git as well, as do for example frequent requests to bisect a 
problem. I moreover feel there's absolutely nothing wrong with that, given 
that there's nothing wrong with git.


It's the kernel's source code management tool, is included out of the box in 
most distributions nowadays and is GPLd meaning that the tool (itself) won't 
keep anyone from exporting data from it and importing it into something else 
if someone cares to. Also, I never managed to stay un-annoyed at source code 
management tools long enough to understand why I wanted to use them but have 
been using git for months now so as far as I am concerned, it appears to 
even be a good tool.


But, well, anyways, I did look at a git repo a bit but will unfortunately 
not be able to follow up the proposal with actual (good) code in a sensible 
timeframe, let alone quickly, which means I was hoping others would agree. 
I believe these properties make for an elegant setup with many possible uses 
including the maintainers information, but if you disagree I guess I'm going 
to shelve it...



Even with git, it is my understanding that kernel community
works largely on patches exchanged over e-mails, between people
who do use git and people who do not.  You would want to have
something you can easily transfer over e-mail in the patch
form.

We _could_ invent a new patches to properties git diff output
format that git apply can understand to propagate that
information


Yes, not unlike the current git move meta-diffs ...

but that approach is making it less interoperable with others, and you 
need to demonstrate the benefit far outweighs that.  I do not see it for 
this particular application.


There may be places for properties that would be useful to git, but I 
do not think the find whom to send patches to is one of them.


The important reason for wiring this into git directly would be keeping the 
meta-data in sync with the data it refers to in an automated fashion. With 
manual intervention, there's much more opportunity for things to grow stale.


In practice, it may not be a huge problem. It certainly is with the current 
MAINTAINERS file but if one does finer-grained data around the tree, that 
will probably help.


It's also not a now or never thing fortunately. If git does ever grow these 
properties, the issue can be revisited, perhaps at that time both with the 
experience of what the finer-grained in-tree solution did not solve and even 
fewer people around that care about not making git even more of an intrinsic 
part of development.


Rene.

-
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: group ownership of tun devices -- nonfunctional?

[Rene Herman]

On 08/19/2007 06:05 PM, Bodo Eggert wrote:


IMHO the check is broken:

+   if (((tun-owner != -1 
+ current-euid != tun-owner) ||
+(tun-group != -1 
+ current-egid != tun-group)) 
+!capable(CAP_NET_ADMIN))
return -EPERM;

It should be something like:

+   if (!((tun-owner == tun-owner) ||
+ (tun-group == tun-group) ||


???


+ capable(CAP_NET_ADMIN)))
return -EPERM;

Please verify and forward to the maintainers if my guess appears to be correct.


Rene.
-
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: group ownership of tun devices -- nonfunctional?

[Rene Herman]

On 08/19/2007 11:42 PM, Bodo Eggert wrote:


On Sun, 19 Aug 2007, Rene Herman wrote:


On 08/19/2007 06:05 PM, Bodo Eggert wrote:


IMHO the check is broken:

+   if (((tun-owner != -1 
+ current-euid != tun-owner) ||
+(tun-group != -1 
+ current-egid != tun-group)) 
+!capable(CAP_NET_ADMIN))
return -EPERM;

It should be something like:

+   if (!((tun-owner == tun-owner) ||
+ (tun-group == tun-group) ||

???


Argh, I edited asuming the same order of variables. Substitute 
current-e{uid,gid} for one of the sides.


Okay. Just had to ask. That looked so odd...


+ capable(CAP_NET_ADMIN)))
return -EPERM;


The intended semantics is If the user is not
 * the allowed user
or
 * member of the allowed group
or
 * cabable of CAP_NET_ADMIN
then error out. I'm asuming


There is a short description of the desired semantics in the link that was 
posted:


http://lkml.org/lkml/2007/6/18/228

===
The user now is allowed to send packages if either his euid or his egid
matches the one specified via tunctl (via -u or -g respecitvely). If both
gid and uid are set via tunctl, both have to match.
===

Paraphrasing the original code above, it's saying:

if ((owner_is_set  does_not_match) || (group_is_set  does_not_match))
bugger_off_unless(CAP_NET_ADMIN);

or reverting the logic:

if ((owner_is_unset || does_match)  (group_is_unset || does_match))
good_to_go();

which probably matches the intention -- we're good to go only if the 
credentials that are set also match.


Rene.
-
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] PS3: Update MAINTAINERS

[Rene Herman]

On 08/21/2007 10:01 PM, Joe Perches wrote:


On Tue, 2007-08-21 at 12:01 -0700, Geoff Levand wrote:



Could you verify that cbe-oss-dev is a subscriber's
only list?  I didn't see anything that said it
specifically in the listinfo.


This is the hold message I got on posting to that list.

Your mail to 'cbe-oss-dev' with the subject

Re: [PATCH] [392/2many] MAINTAINERS - PS3 PLATFORM SUPPORT

Is being held until the list moderator can review it for approval.

The reason it is being held:

Post by non-member to a members-only list


That means it's not a subcriber-only list -- the message wasn't rejected, 
just subjected to moderation.


Rene.

-
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] PS3: Update MAINTAINERS

[Rene Herman]

On 08/21/2007 10:17 PM, Geoff Levand wrote:


Rene Herman wrote:

On 08/21/2007 10:01 PM, Joe Perches wrote:



The reason it is being held:

Post by non-member to a members-only list
That means it's not a subcriber-only list -- the message wasn't rejected, 
just subjected to moderation.




So maybe it would be more precise to have something like this:

-L: [EMAIL PROTECTED]
+L: [EMAIL PROTECTED]   (moderated)


Perhaps. In these spamridden days, mailinglists that don't have the kind of 
(human and other) resources behind them that linux-kernel has basically have 
the choice between drowning in spam, becoming subscriber only or moderate 
non-subscribers and of these, that third option is best among the bad.


alsa-devel for example also went this route -- the spam levels simply 
weren't tolerable anymore for any subscriber and the list was dying as a 
result. Moderation sucks, but subcriber-only sucks even worse (generally, 
and/but even more so for lists that expect crossposts from linux-kernel) so 
what's a small-time list to do.


Moderation takes some effort so the lists that moderate have made the 
explicit choice to not become subscriber-only. While subscriber-only 
certainly is useful to mention alongside the list address itself, I'm not 
too sure mentioning moderation makes a great deal of sense actually -- if 
all's well, the moderator will simply approve it and you don't have to deal 
with it other than that.


Rene.

-
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] PS3: Update MAINTAINERS

[Rene Herman]

On 08/21/2007 10:48 PM, Satyam Sharma wrote:

That means it's not a subcriber-only list -- the message wasn't rejected, 
just subjected to moderation.


That's precisely a subscribers-only list. At least as per MAINTAINER's
definition of that term. It'd be surprising to know of a mailing list
mentioned in MAINTAINERS that _drops_ messages posted to it entirely!


Then its definition does not make any sense whatsoever -- as said just now 
as well, moderation takes some effort so lists that do have made the 
explicit choice to _not_ become subscriber-only.


Moderation is furthermore not something the poster needs to concern himself 
with, other than through being aware of a possible delay. It's mostly those 
poor moderators that wade through bucket-loads of spam that care... ;-)


Rene.
-
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 with IDE on linux 2.6.22.X

[Rene Herman]

On 08/21/2007 09:49 PM, José Luis Patiño Andrés wrote:


Somebody tolds me that I can solve this problem unchecking the
IDE_GENERIC option in the kernel configuration. It's true, but when I do
this the DVD device is not recognized by the kernel. No exists.


The OpenSuSE Live CD thing not booting may mean you have a deeper problem,
but please note that you shouldn't be using ide-disk:


In my working 2.6.20.15 kernel, the 'cat /proc/ide/drivers' command
outputs this:



###
#ide-disk   version 1.18
#ide-cdrom  version 4.61
###

But in 2.6.22.X, the output is only:
###
#ide-disk   version 1.18
###


You have a SATA harddrive (Hitachi Travelstar 5K100 100GB SATA/2.5) and an
IDE (also known as PATA) DVD drive (LG GMA-4082N). That is, your disk should 
be driven by the:


Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support

under the Serial ATA (prod) and Parallel ATA (experimental) drivers menu, 
and it seems this driver should also take care of your DVD. Not sure from 
your report what you are using -- first try with only that driver, and 
nothing from the old ATA/ATAPI/MFM/RLL support menu selected.


In that situation, your harddrive works, but your DVD does not?

If so, this should be fixed in the driver, but to get things working I 
believe you may try with both the above driver for your harddisk and the old 
IDE driver for the DVD:


*   Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support
* Include IDE/ATAPI CDROM support (NEW)
[*] PCI IDE chipset support
[*] Generic PCI bus-master DMA support
*   Intel PIIXn chipsets support

(do not select IDE/ATA-2 disk support)

where you may need to boot with a libata.atapi_enabled=0 kernel parameter.

Not actually particularly sure if that works given that it's the same chip 
and all it seems but anyways, please first verify results with only that 
SATA driver.


Rene.
-
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 with IDE on linux 2.6.22.X

[Rene Herman]

On 08/22/2007 01:00 AM, Alan Cox wrote:


Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support


Not for the newer chips. You want ATA/SATA (PIIX and possibly AHCI)
support from the new drivers, SCSI disk and SCSI cd.


That _is_ the *config description for the new (CONFIG_ATA_PIIX) driver (in 
2.6.22.x).



where you may need to boot with a libata.atapi_enabled=0 kernel parameter.


Why deliberately disable atapi when you need atapi ?


Because he described the problem that if he got his (SATA) disk supported he 
lost his (PATA) DVD drive. Although I'm as said not completely sure it would 
actually work, I suggested compiling in both ATA_PIIX (yes, and sd) for his 
drive and the IDE PIIX/ICH driver and ide-cd for his DVD, where if it works 
at all, passing the above option may or may not be useful.


But his report, although expansive, was a little unclear. Let's wait for 
what happens with only ATA_PIIIX.


Rene.
-
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/