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;
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
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
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,
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
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
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
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
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
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
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
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
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
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]
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
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
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
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
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.
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
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
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
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
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
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
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
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
, 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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_
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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))
+
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
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
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
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
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
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
201 - 300 of 1135 matches
Mail list logo
