Now that Google has launched its new Groups2 feature, the script I used to determine the proper archive URL for each thread has broken. If anyone feels like scripting up a replacement I would be very grateful.
Note that searching on message-id doesn't work, because Google uses an NNTP gateway that replaces the true message-id with something else. It would be perfect if the script produced urls looking like <http://groups-beta.google.com/group/linux.kernel/msg/c0abc11b6964b63a>, which is obtained by clicking on the 'show options' part of an email in Groups2, and then selecting the 'Individual Message' option.
Andrea Arcangeli said, This is the forward
port to 2.6 of the lowmem_reserved algorithm I invented in 2.4.1*, merged in
2.4.2x already and needed to fix workloads like google (especially without
swap) on x86 with >1G of ram, but it's needed in all sort of workloads
with lots of ram on x86, it's also needed on x86-64 for dma allocations. This
brings 2.6 in sync with latest 2.4.2x.
Nick Piggin took a look at
this, and felt that it really simplified the code. But he asked, should it be on by default? I don't think we ever reached
an agreement. I'd say yes, after a run in -mm because it does potentially
fix corner cases where lower zones get filled with un- freeable memory
which could have been satisfied with higher zones.
Andrea replied,
I definitely agree it should be on by default,
I already had an hang report that was solved by more recent kernels and that
probably can only be explained by lowmem_reserve since there aren't other
mm changes in 2.6.5 based trees.
Nick in his original post, also asked if Andrea could port his patches
to Andrew Morton's -mm tree; Andrea said, I
already had to port to 2.6.5 too, and that's enough for now unless I first
get a positive ack that it will be merged (if I hadn't more interesting
things to develop, I would be happily porting it).
Marcelo Tosatti
replied, I believe it can be accepted easily if
you change the variable names from protection to lowmem_reserve. Is there
a need for that or its just your taste? :)
Andrea replied:
The naming is in sync with 2.4, I called that feature lowmem_reserve when I wrote it. Protection doesn't actually mean anything. Memory protection, mprotect, what?
The object of the feature is to reserve lower memory in function of the classzone allocation, and in function of the zone we're allocating from. So lowmem_reserve sounds a much better name. And it wasn't me to change it, it was the 2.6 kernel calling it differently in the first place. Note that at first 2.6 was doing stuff very differently from 2.4 too (and it wasn't working right infact). Now it's in perfect sync with the 2.4 algorightm I wrote originally and so I thought it would be much cleaner to call it the same way as 2.4, which is more self explanatory too.
Linus Torvalds announced Linux 2.6.10, saying:
Ok, with a lot of people taking an xmas break, here's something to play with over the holidays (not to mention an excuse for me to get into the Glögg for real ;)
Mostly a lot of small fixes since 2.6.10-rc3, with the biggest thing being probably the CIFS update and the switch-over to the new DVB frontend driver world order. Some MMC and USB work too, and ARM updates as usual.
In the course of discussion, Wichert Akkerman reported, 2.6.10 broke resume for me: when I resume it immediately tries
to suspend the machine again but gets stuck after suspending USB.
Rafael J. Wysocki also had trouble resuming after a suspend under 2.6.10,
but only once in awhile. Pavel Machek took a stab at this, but it turned out
Rafael was using AMD64, wihle Pavel was patching the i386 code. Debugging
efforts stalled completely at that point, and the discussion petered out.
Pavel Machek said:
Some machines are spending minutes of CPU time during suspend in stupid O(n^2) algorithm. This patch replaces it with O(n) algorithm, making swsusp usable to some people.
I'd like people to test this. It should probably spend few weeks in -mm tree to get some beating. OTOH SUSE has variant of this patch in its kernel.
Someone reported tremendous improvements with this patch, saying that
their system would suspend in about 5 seconds, as opposed to a minute or more
without Pavel's patch. Eduard Bloch also found it very stable and reliable,
even after many many uses. And Rafael J. Wysocki added, Confirmed. I've been running it for quite some time with 2.6.10
on an AMD64 and it works great.
Alan Cox announced Linux 2.6.10-ac1, saying:
Linux 2.6.10-ac1 is a merge of the stuff that has not yet been accepted upstream along with a couple of small extra changes that are needed because of changes in 2.6.10 base. In addition the generic IRQ work in 2.6.10 means that the forward port of the irqpoll code now covers a lot more platforms.
While this has had a lot less testing than 2.6.9-ac16 it does contain much better core USB and SCSI code so may in some cases be worth an early move.
Arjan van de Ven is now building RPMS of the kernel and those can be found in the RPM subdirectory and should be yum-able. Expect the RPMS to lag the diff a little as the RPM builds and tests do take time.
Gene Heskett, who had been having problems getting Samba to work under 2.6.10, found that these problems vanished with 2.6.10-ac1, and that he could mount and unmount Samba shares in small fractions of a second, better than he'd ever seen before. He did run into a lot of warning messages, but according to Alan these may have just been old errors exposed by the improved code. They didn't seem to interfere with Samba usage.
Alan Cox said, The serverworks chips include a
raid variant that the 2.6 driver didn't support. This
[patch] enables support for this and removes a pile of #if and other
pointless obfuscations. This removes the need to use various vendor binary
only drivers for CSB6 RAID
. Bartlomiej Zolnierkiewicz liked the patch
and accepted it for his set of submissions heading for Linus Torvalds.
Matthias Kunze said, I just wanted to
announce that I've updated the Enhanced Linux Progress Patch to work with
linux 2.6.10. As it doesn't seem to be maintained anymore i've put up a tiny
homepage at http://elpp.foofighter.de
where everything can be downloaded.
Alan Cox announced Linux 2.6.10-ac2, saying, Arjan
van de Ven is now building RPMS of the kernel and those can be found in the
RPM subdirectory and should be yum-able. Expect the RPMS to lag the diff
a little as the RPM builds and tests do take time.
Christian Hesse
noticed that the PWC driver, newly restored to 2.6.10-ac2 by Luc Saillard,
could only be built as a module. Christian posted a patch to allow it also
to be built directly into the kernel.
Adrian Bunk announced util-linux version 2.12q-pre1, and confirmed Andries Brouwer's statements that Adrian was now the maintainer of that project. In fact, part of Adrian's patch was an update to the MAINTAINERS file.
Andries first put util-linux up for adoption in the thread covered in
Someone asked how best to get started with kernel development,
and Christoph Anton Mitterer (another newcomer) pointed him to
Kernelnewbies. Jim
Nelson said, Hit http://www.dit.upm.es/~jmseyas/linux/kernel/hackers-docs.html
- has a good selection of dead-tree and
online references. The kernel-janitors project - http://www.kerneljanitors.org/
- is a good starting point; that's where a lot of kernel hackers get their
start.
Pedro Venda also remarked:
this has been very recently asked on the list. some of the suggested answers were:
books:
- linux kernel development by robert love
- linux device drivers by Alessandro Rubini and Jonathan Corbet.
- understanding linux kernel by Daniel P. Bovet and Marco Cesati.
(last two will have new editions soon covering 2.6 kernels)
Deepak Kotian had read and liked 'Linux Kernel Development', but wondered
when the 3rd edition of 'Linux Device Drivers' would be out; and Jonathan
Corbet replied, LDD3 (by Jonathan Corbet,
Alessandro Rubini, and Greg Kroah-Hartman) will, it is hoped, be ready to
be the star of the show at LinuxWorld in Boston, next month. The online
release will, as usual, take some time to prepare; I can't predict just when
that will be.
Christoph Hellwig reported:
There's been a bugtraq report about a root exploit with modular capabilities LSM support out for more than a week.
This patch fixes it the hard way by disallowing to build the code modular. In fact I think allowing modular security policies is a really, really bad idea because loading it after boot loses far too much state. Would you take a patch killing the exports in security/ ?
Lee Revell replied, And I posted this
to LKML almost a week ago, and a real fix was posted in response. http://lkml.org/lkml/2004/12/28/112
.
Linus Torvalds replied, Well, I realize that
it has been on bugtraq, but does that make it a real concern? I'll make
the tristate a boolean, but has anybody half-way sane ever _done_ what is
described by the bugtraq posting? IOW, it looks pretty much like a made-up
example, also known as a "don't do that then" kind of buglet ;)
Christoph agreed that this particular case probably wasn't much to worry
about, but he said, I think we'll see more
serious issues with other modular security modules. The security modules
aren't really as isolated as all the driver modules we have as they're
deeply interwinded with the process/file/etc state.
And Chris Wright
replied, It's only a problem when you care about
the state of things that have run before the module is loaded. This ranges
between no problem and major problem on a case by case basis. For example,
really makes sense to have SELinux only compiled in. For this one, we can
just track capabilities bits in default dummy stub code, it's painless and
allows keeping capabilities modular for those who use it that way.
Domen Puncer posted a patch against the MAINTAINERS file, to mark the linux-arm-kernel mailing list as requiring subscription to post.
H. Peter Anvin said, This patch adds a set of
ioctls to get and set the FAT filesystem native attribute bits, including the
unused bits (6 and 7.)
Nicholas Miell suggested, Instead of adding another ioctl, wouldn't an xattr be more appropriate?
For instance, system.fatattrs containing a text representation of the attribute
bits.
H. Peter replied, This really worries
me, because it's not clear to me that Microsoft isn't going to add NTFS-style
xattrs to FAT in the future. There is a very specific reason why they might
want to do that: since they want to keep NTFS secret and proprietary, FAT is
the published interchange format that other devices can use to exchange data
with MS operating systems. If we then have overloaded the xattr mechanism,
that would be very ugly.
Nicholas replied:
That's why I put fatattrs in the system namespace, which is wholly owned by the Linux kernel. Any theoretical FAT-with-xattrs variant would put those xattrs in the user namespace.
On another note, NTFS-style xattrs (aka named streams) are unrelated to Linux xattrs. A named stream is a separate file with a funny name, while a Linux xattr is a named extension to struct stat.
This made sense to H. Peter, and they dove into some technical details together.
H. Peter Anvin said:
I recently posted to LKML a patch to get or set DOS attribute flags for fatfs. That patch used ioctl(). It was suggested that a better way would be using xattrs, although the xattr mechanism seems clumsy to me, and has namespace issues.
I also think it would be good to have a unified interface for FAT, NTFS and CIFS for these attributes.
I noticed that CIFS has a placeholder "user.DosAttrib" in cifs/xattr.c, although it doesn't seem to be implemented.
Questions:
a) is xattr the right thing? It seems to be a fairly complex and ill-thought-out mechanism all along, especially the whole namespace business (what is a system attribute to one filesystem is a user attribute to another, for example.)
b) if xattr is the right thing, shouldn't this be in the system namespace rather than the user namespace?
c) What should the representation be? Binary byte? String containing a subset of "rhsvda67" (barf)?
Anton Altaparmakov said, definitely not the string subset in item (c). He said:
In NTFS, the "dos attribute flags" are part of the system information attribute which is an entity in its own right, totally separate from extended attributes (and named streams for that matter). So if I were to be thinking in an NTFS-only world I would be inclined to use an ioctl() to access/modify them (i.e. not b either). So if you implement an ioctl() for vfat I will probably be able to provide the same in NTFS with almost zero effort (we already have the code to read and write the attribute flags in the kernel ntfs driver, we just do not provide an interface for it).
But please note that it would be best if you could use 32-bits for the flags. At the very least 16-bits though as on NTFS there are currently in use 16-bits in the standard information but the field is u32 sized on disk (little endian) and two of the higher bits are in use in the file name attribute as well and I would not be surprised if more bits get used in future NTFS releases.
Nicholas Miell thought there was nothing wrong with the string subset idea; while on the other hand he felt an ioctl would definitely be the wrong way to go. He said:
Remember, the point of this exercise is to expose these attributes in such a way that tools don't have to have any special knowledge to correctly preserve them.
If I want to be able to copy files from one NTFS volume to another (preserving all their NTFS attributes), I don't want to have to teach cp to run a Linux-specific and NTFS-specific ioctl on each file on the source and destination for it to work, it should be able to see the xattrs and just do the right thing.
The fact that the NTFS "dos attribute flags" are seperate from real extended attributes isn't a problem, either. Real extended attributes can be exported in the user namespace, just like ext2/3 does. (Or are the real extended attributes something other than inert blobs of data -- does Windows care about their contents at all, or does it just store them for users who do?)
Regarding the string subset issue, Anton argued that strings could get really ugly, and could be a problem for internationalization; while binary was shorter and better-defined. He said if a string was desired, a translation library would be the way to go, keeping binary in the back-end.
Regarding ioctl vs. xattr, Anton and Nicholas continued to disagree, without reaching any resolution. Nicholas said he didn't really care about the string vs. binary issue, saying he'd only suggested the string idea for the sake of readability of /proc files and other places.
Other folks duked it out elsewhere as well, with about as much agreement.
Olaf Hering said:
A few users of request_irq pass a string with '/'. As a result, ls -l /proc/irq/*/* will fail to list these entries.
drivers/input/serio/maceps2.c | 2 +- drivers/macintosh/via-pmu.c | 2 +- drivers/net/wan/hostess_sv11.c | 2 +- include/asm-sh/mpc1211/keyboard.h | 2 +- include/asm-sh64/keyboard.h | 2 +- sound/isa/opl3sa2.c | 2 +-
Andrew Morton replied:
hrm, interesting. So how do these entries appear in /proc? Do they actually have slashes in them?
I get the feeling that something somewhere should be detecting this and should be propagating an error back.
Olaf agreed that a quick sanity check would help, and clarified, ls /proc/irq/*/* works, but ls -l does not because you
have to stat() the entry. I havent looked in detail, just poked around in
/proc.
Nathan Lynch tried hacking up the sanity check, but the thread petered out inconclusively.
Itsuro Oda said:
We released the Beta-3 version of mkdump end of last year.
We checked the code from crash occur to the mini kernel start carefully and eliminate the possibility of the deadlock/hang condition. (We hope :-))
Please check it.