Original Toner Cartridge promotion
Dear All Customers, === Original Toner Cartridge promotion === HP toner: 1) C7115A = RM170; 2) C3906F = RM175; 3) Q2612A = RM 199; 4) Q5949A = RM 199; Samsung toner: 1) ML-1710 = RM 249; 2) ML-2010 = RM 239; Xerox toner: 1) 203A = RM 149; ** ADVANTAGES : Printer repairs & services available ** To REDUCE or SAVE more cost, please do not hesitate to contact us for more information. regards, Mr Ken Tel: 012-366 2818 IT CITY COMPUTER 46M, Jalan Wangsa 2/5, Taman Wangsa Permai, Kepong 52100. Kuala Lumpur. Tel: 03-6276 3561 Fax: 03-6272 9718 Email: [EMAIL PROTECTED] - pls refer to terms & conditions - 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/
Does linux kernel support little-endian on powerpc?
Hi All, I know toolchain support the target powerpcle-elf. it enable the little-endian on powerpc. I see that there is -melf32ppc param for ld in arch/ppc/Makefile. Can I modify it to -melf32lppc? what will occur? Can kernel suport little-endian on powerpc well? thanks Jason - 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: Using cramfs as root filesystem on diskless machine
Alexandr Andreev wrote: > > David L. Parsley wrote: > > >Mathias Killian wrote a patch to allow cramfs initrd's, see: > >http://www.cs.helsinki.fi/linux/linux-kernel/2001-01/1064.html > > > Thank you. I applied this patch, and recompiled my kernel. > All works fine, if the size of root filesystem less than 4096Kb. But > when i create > an image of root filesystem which size is bigger than 4096Mb, the kernel > said: > ... > RAMDISK driver initialized: 16 RAM disks of 4096K size 4096 blocksize ^ You also need to give the kernel 'ramdisk_size='. I've used larger cramfs initrd's with no problem, but the kernel has to make larger ramdisks. By editing rd.c, you can make this stuff default. regards, David -- David L. Parsley Network Administrator, Roanoke College "If I have seen further it is by standing on ye shoulders of Giants." --Isaac Newton - 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: Using cramfs as root filesystem on diskless machine
Mathias Killian wrote a patch to allow cramfs initrd's, see: http://www.cs.helsinki.fi/linux/linux-kernel/2001-01/1064.html Alexandr Andreev wrote: > > Hi, list. > > My MIPS machine has no any disks or flopies. So i obliged to use a RAM > disk with a file system on it, which is mounted as root. > I use gzipped initrd image, which is linked to the special section in the > kernel during compilation. Now, the RAM disk size is really big, so i > decide > to use cramfs instead of ext2. In scripts/cramfs/ I found an utility that > creates cramfs file system image. But i read in rd.c, that RAM disk driver > doesn't support the cramfs. > > After i create an image, how can i mount it as root file system? Where i > must put it? Which kernel command line options i must use? > > Please answer, or point me to any documentation or mailing list. > > - > 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/ -- David L. Parsley Network Administrator, Roanoke College "If I have seen further it is by standing on ye shoulders of Giants." --Isaac Newton - 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: [CFT][PATCH] namespaces patch (2.4.5-pre6)
Alexander Viro wrote: > > Folks, new version of the patch is on > ftp.math.psu.edu/pub/viro/namespaces-c-S5-pre6.gz > > News: > * ported to 2.4.5-pre6 > * new (cleaner) locking mechanism > * lock_super() is starting to become fs-private thing - first steps to > removing it from VFS code are done. > > Please, help with testing. I'm feeding the pieces suitable for 2.4 into > the Linus' tree, so patch got smaller. OK, at the risk of asking a Stupid Question (tm), what exactly does the namespaces patch buy us? From the viewpoint of an integrator/system admin? I'd happily check it out if I thought it would solve any of the problems I regularly see. regards, David -- David L. Parsley Network Administrator, Roanoke College "If I have seen further it is by standing on ye shoulders of Giants." --Isaac Newton - 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] rootfs (part 1)
Linus Torvalds wrote:
> What the hell are you doing? Compiling with debugging or something?
I'll bet he's using a rootkit 'ls' that shows file sizes in bits.
;-)
regards,
David
--
David L. Parsley
Network Administrator, Roanoke College
"If I have seen further it is by standing on ye shoulders of
Giants."
--Isaac Newton
-
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: ramdisk/tmpfs/ramfs/memfs ?
David Woodhouse wrote:
> Why copy it into RAM? Why not use cramfs and either turn the writable
> directories into symlinks into a ramfs which you create at boot time, or
> union-mount a ramfs over the top of it?
^^^
I didn't think we had union-mounting support... does it exist and
I've somehow missed it?
regards,
David
--
David L. Parsley
Network Administrator
Roanoke College
-
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: hundreds of mount --bind mountpoints?
Christoph Rohland wrote: > > OK I will do that for tmpfs soon. And I will do the symlink inlining > with that patch. Wow, this thread really exploded, eh? But thanks, Christoph, I look forward to seeing your patch. 4k symlinks really suck for embedders who never swap out pages. ;-) regards, David -- David L. Parsley Network Administrator Roanoke College - 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: Idea: Encryption plugin architecture for file-systems
Dale Amon wrote: > > Talk about syncronicity... I had just last week asked > about the pro's and con's on this on the crypto list and > have heard nothing at all back. So I'll drop the body > of that message in here: why not port one of the twenty or thirty preexisting tools that let you mount a filesystem from an encrypted file instead of making a generic layer? That way you could have inter-os portability. The steganographic ones make really impressive claims. Does linux have a truly generic plug-in file system module yet, or are people still hacking around fake nfs servers? -- David Nicol 816.235.1187 [EMAIL PROTECTED] "Described as awesome by users" - 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: hundreds of mount --bind mountpoints?
Christoph Rohland wrote: > > Hi David, > > On Sun, 22 Apr 2001, David L. Parsley wrote: > > I'm still working on a packaging system for diskless > > (quasi-embedded) devices. The root filesystem is all tmpfs, and I > > attach packages inside it. Since symlinks in a tmpfs filesystem > > cost 4k each (ouch!), I'm considering using mount --bind for > > everything. > > What about fixing tmpfs instead? That would be great - are you volunteering? ;-) Seriously - I might be able to look at what ramfs does and port that to tmpfs for my needs, but that's about the extent of my kernel hacking skills. For now, mount --bind looks like it'll work just fine. If somebody wants to fix tmpfs, I'll be happy to test patches; it'll just change a couple of lines in my package loading logic (mount --bind x y -> ln -s x y). What I'm not sure of is which solution is actually 'better' - I'm guessing that performance-wise, neither will make a noticable difference, so I guess memory usage would be the deciding factor. If I can get a lot closer to the size of a symlink (10-20 bytes) that would be best. The issue with /proc/mounts really shouldn't hurt anything - I could almost get by without mounting /proc anyway, it's mainly a convenience. regards, David -- David L. Parsley Network Administrator Roanoke College - 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/
hundreds of mount --bind mountpoints?
Hi,
I'm still working on a packaging system for diskless (quasi-embedded)
devices. The root filesystem is all tmpfs, and I attach packages inside
it. Since symlinks in a tmpfs filesystem cost 4k each (ouch!), I'm
considering using mount --bind for everything. This appears to use very
little memory, but I'm wondering if I'll run into problems when I start
having many hundreds of bind mountings. Any feel for this?
regards,
David
--
David L. Parsley
Roanoke College Network Administrator
-
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/
union mounting?
Hi Alex, I'm working on an embedded distro, and it would be nice if I could just mount 'packages' over the top of one another; each 'package' is a cramfs filesystem. I'm currently using a bunch of symlink stuff, but it's not real pretty. If you've got union mounting patches for testing, I'd be interested. ;-) regards, David -- David L. Parsley Network Administrator Roanoke College - 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/
Dell 4300 + megaraid
Our Dell 4300, plus raid card, works okay with a 2.2.14 kernel, which has a version 107 megaraid.o module. This is many versions behind the version present in 2.4.3. More recent driver modules for the card hand on booting, thus this problem report. The module source does not indicate a recent contact person for discussing the module, all of the updates since 1998 are unsigned. Advise? - 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/
/proc/sys/vm/freepages read-only?!?
Hi, I'm trying to do some vm tuning for diskless (and therefore swapless) devices. (I'm working on a distro that tftp's packages and runs entirely in RAM) Even on an X terminal with 64MB RAM, badly behaved apps can use lots of ram in the Xserver, and what I'm seeing is a hang. The box is usually still pingable, just unresponsive. I'm using cramfs pretty heavily, and I think what's occuring is that the terminal gets too low on freepages, and since pages used by X can't be swapped out, the box starts thrashing the vm and is unable to get pages to uncompress into. My first thought was echo (bigger numbers) > /proc/sys/vm/freepages - but lo! - it's not writable anymore. I found comments in page_alloc.c indicating it had to be read-only, but it seems it's only a safety precaution. Something along the lines of values too small being 'bad bad'. help? David -- David L. Parsley Network Administrator Roanoke College - 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: What is 2.4 Linux networking performance like compared to BSD?
Alan Cox wrote: > The extreme answer to the 2.4 networking performance is the tux specweb > benchmarks but they dont answer for all cases clearly. However, I think you've hit the nail on the head here; much of tux is just general-purpose network file-blasting. The right hacker could turn it into the fastest web-cache on the planet with the right modules. I believe Ingo already did a basic ftp server based on tux, just to demonstrate this generality. Ingo? Am I crazy or enlightened? regards, David - 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][CFT] per-process namespaces for Linux
Alexander Viro wrote:
> > Evil idea of the day: non-directory (even non-existant) mount points and
> > non-directory mounts. So then "mount --bind /etc/foo /dev/bar" works.
>
> Try it. It _does_ work.
Yeah, mount --bind is cool, I've been using it on one of my projects
today. But - maybe I'm just not thinking creatively enough - what are
the advantages of mount --bind versus just symlinking?
Also, I tried mount --bind fileone filetwo, and it fails if filetwo
doesn't exist. ('mount point filetwo doesn't exist'). Is that supposed
to work? (using mount from latest redhat beta)
BTW, pivot_root is nifty, too. ;-)
regards,
David
--
David L. Parsley
Network Administrator
Roanoke College
-
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/
another Linux-2.4.2 splat: *** target pattern contains no `%'. Stop.
[david@nicol1 linux]$ make dep make[3]: Entering directory `/mnt/sdb2/src/linux-2.4.2/drivers' make -C acpi fastdep make[4]: Entering directory `/mnt/sdb2/src/linux-2.4.2/drivers/acpi' Makefile:29: *** target pattern contains no `%'. Stop. make[4]: Leaving directory `/mnt/sdb2/src/linux-2.4.2/drivers/acpi' make[3]: *** [_sfdep_acpi] Error 2 make[3]: Leaving directory `/mnt/sdb2/src/linux-2.4.2/drivers' make[2]: *** [fastdep] Error 2 make[2]: Leaving directory `/mnt/sdb2/src/linux-2.4.2/drivers' make[1]: *** [_sfdep_drivers] Error 2 make[1]: Leaving directory `/mnt/sdb2/src/linux-2.4.2' make: *** [dep-files] Error 2 - 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: Will Mosix go into the standard kernel?
Zack Brown wrote: > > Just curious, are there any plans to put Mosix into the standard kernel, > maybe in 2.5, so folks could just configure it and go? it seems that the > number of people with more than one computer might make this a feature many > would at least want to try, especially if it was available as an option by > default. Is there anything in the Mosix folks' implementation that would > prevent this? I'm not a knowledgeable person, but I've been following Mosix/beowulf/? for a few years and trying to keep up. I've thought that it would be good to break up the different clustering frills -- node identification, process migration, process hosting, distributed memory, yadda yadda blah, into separate bite-sized portions. Centralization would be good for standardizing on what /proc/?/?/? you read to find out what clusters you are in, and whatis your node number there. There is a lot of theorhetical work to be done. Until then, I don't expect to see the Complete Mosix Patch Set available from ftp.kernel.org in its current form, as a monolithic set that does many things, including its Very Own Distributed File System Architecture. If any of the work from Mosix will make it Into The Standard Kernel it will be by backporting and standardization. Is there a good list to discuss this on? Is this the list? Which pieces of clustering-scheme patches would be good to have? I think a good place to start would be node numbering. The standard node numbering would need to be flexible enough to have one machine participating in multiple clusters at the same time. /proc/cluster/ this would be standard root point for clustering stuff /proc/mosix would go away, become proc/cluster/mosix and the same with whatever bproc puts into /proc; that stuff would move to /proc/cluster/bproc Or, the status quo will endure, with cluster hackers playing catch-up. -- David Nicol 816.235.1187 [EMAIL PROTECTED] "Americans are a passive lot, content to let so-called experts run our lives" -- Dr. Science - 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: bidirectional named pipe?
According to the Understanding the Linux Kernel book I plowed through yesterday afternoon the EXT2 file system has a defined file type "socket," distinct from fifo. How does one set up a named socket in a file system? Is it a legacy constant that has never been supported or what? "David L. Nicol" wrote: > > Alan Cox wrote: > > > > > I'm porting some software to Linux that requires use of a bidirectional, > > > named pipe. The architecture is as follows: A server creates a named pipe > > > > Pipes are not bidirectional in Linux. We follow traditional non stream > > behaviour > > > > > /dev/spx". I experiemented with socket-based pipes under Linux, but I > > > couldn't gain access to them by open()ing the name. Is there help? I > > > > AF_UNIX sockets are bidirectional but like all sockets use bind() and > > connect(). > You could patch the file system code, I wonder how deep the changes would have > to be, if you did it in terms of lots of fifos. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- David Nicol 816.235.1187 [EMAIL PROTECTED] "I don't care how they do it in New York" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
book review: Understanding the LINUX Kernel
Understanding the Linux Kernel Daniel P. Bovet and Marco Cesati O'Reilly, 2000 Book web site (including a sample chapter) is here: http://www.oreilly.com/catalog/linuxkernel/ Developed and tested as lecture notes for university classes in which the 2.2 kernel was examined, the new O'Reilly book Understanding The LINUX Kernel is an exhaustive enumeration of features of the ascendent modern platform. If you want to know more about what is involved in writing device drivers, or respect the complexity required to pull off a trick like MOSIX, and the flexibility of a platform that provides a ptrace() debugging function that makes it easy, this book may be for you. I fear the book would have made much less sense to me had I not taken university courses in microprocessor architecture and OS theory, but then I would not have been able to skim those parts, clear and concise, quite as quickly as I did. It is written clearly, and is full of internal references to other chapters where ideas are expanded, to see how it all works together. Instructions are given, for instance, on how to fiddle your kernel configuration so that microsoft windows programs are recognized from their magic signatures and WINE can be invoked to handle them; and other advanced 2.2 features. Each chapter ends with the most up-to-date information about changes for 2.4 that were available at the end of 2000; such as the increased number of local kernel locks and the improved VM page swap donor selection algorithm. Occasional assertions that do not match my understanding do appear, such as a bit on scheduling that seems to imply that a "fair scheduling patch" is a standard item instead of an option; I suspect it had been applied to the kernels examined in the class setting, as it would make a very tidy little homework assignment. At the end of the book there is an index of routines against the files they are found in. http://www.amazon.com/exec/obidos/ASIN/059622/tipjartransactioA The preface claims that facts were checked by Alan Cox himself. -- David Nicol 816.235.1187 [EMAIL PROTECTED] "I don't care how they do it in New York" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bidirectional named pipe?
Alan Cox wrote: > > > I'm porting some software to Linux that requires use of a bidirectional, > > named pipe. The architecture is as follows: A server creates a named pipe > > Pipes are not bidirectional in Linux. We follow traditional non stream > behaviour > > > /dev/spx". I experiemented with socket-based pipes under Linux, but I > > couldn't gain access to them by open()ing the name. Is there help? I > > AF_UNIX sockets are bidirectional but like all sockets use bind() and > connect(). How hard would it be to add? The limitation on fifos that you get the same one every time you open it makes some things tricky -- the server has to move the fifo and mkfifo a new one to replace its data with something else, for instance, which is not atomic. I don't understand, in the original problem, how the server opens the named bipipe differently from the servers, to be on one end rather than the other. A way to map a file name to a socket pair would be nice, the first to open it could get one end of it and everyone else would get the other end, or there would be a switch. You could patch the file system code, I wonder how deep the changes would have to be, if you did it in terms of lots of fifos. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: OK to mount multiple FS in one dir?
Peter Samuelson wrote: > A more useful thing to fall out of the same hacking is loopback > mounting -- i.e. the same filesystem mounted multiple places. In > Linux-land I guess we call it 'mount --bind'. > > Peter Does this kind of thing play nice with nfs and coda, in terms of change notifications and write-backs? In distributed FS we've got the same thing mounted multiple places, of course, but not on the same machine -- David Nicol 816.235.1187 [EMAIL PROTECTED] Pedestrians always have the right of way - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: How can I understand Linux Network implementation?
Donghui Wen wrote: > > I am hacking the implementation of linux2.4's > networking (IPV4) . Can anyone give me some idea > what material I should read to understand the > data structures and algorithms. I have stevens's > books which talked about BSD's implementation. > > Thanks! > > Donghui Print it all out read the source code I like the a2ps tool for formatting source code for reading; I print out a sheaf of source code and retreat to a local coffee emporium with a highlighter and a legal pad. -- David Nicol 816.235.1187 [EMAIL PROTECTED] 2.4.0 seems faster than 2.2.16 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
"no such 386 instruction" with gcc 2.95.2
I think I must need to upgrade my assembler, but:
2.4.0/Documentation/Changes does not list an assembler version.
make[2]: Entering directory `/mnt/sdb2/src/linux-2.4.0/drivers/md'
gcc -D__KERNEL__ -I/mnt/sdb2/src/linux-2.4.0/include -Wall -Wstrict-proto
types -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-sta
ck-boundary=2 -march=i586 -DMODULE -DMODVERSIONS -include /mnt/sdb2/src/l
inux-2.4.0/include/linux/modversions.h -DEXPORT_SYMTAB -c xor.c
{standard input}: Assembler messages:
{standard input}:996: Error: no such 386 instruction: `movups'
{standard input}:997: Error: no such 386 instruction: `movups'
{standard input}:998: Error: no such 386 instruction: `movups'
{standard input}:999: Error: no such 386 instruction: `movups'
{standard input}:1001: Error: no such 386 instruction: `prefetcht0'
{standard input}:1002: Error: no such 386 instruction: `prefetcht0'
{standard input}:1005: Error: no such 386 instruction: `movaps'
{sta...
...
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Five seconds of light is a lot of data.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Is sendfile all that sexy?
Jakub Jelinek wrote: > > This makes me wonder... > > > > If the kernel only kept a queue of the three smallest unused fd's, and > > when the queue emptied handed out whatever it liked, how many things > > would break? I suspect this would cover a lot of bases... > > First it would break Unix98 and other standards: [snip] Yeah, I reallized it would violate at least POSIX. The discussion was just bandying about ways to avoid an expensive 'open()' without breaking lots of utilities and glibc stuff. This might be something that could be configured for specific server environments, where performance is more imporant than POSIX/Unix98, but you still don't want to completely break the system. Just a thought, brain-damaged as it might be. ;-) regards, David -- David L. Parsley Network Administrator Roanoke College - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Is sendfile all that sexy?
Felix von Leitner wrote:
> > close (0);
> > close (1);
> > close (2);
> > open ("/dev/console", O_RDWR);
> > dup ();
> > dup ();
>
> So it's not actually part of POSIX, it's just to get around fixing
> legacy code? ;-)
This makes me wonder...
If the kernel only kept a queue of the three smallest unused fd's, and
when the queue emptied handed out whatever it liked, how many things
would break? I suspect this would cover a lot of bases...
regards,
David
--
David L. Parsley
Network Administrator
Roanoke College
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] one-liner fix for bforget() honoring BH_Protected; was: Re: Patch (repost): cramfs memory corruption fix
Linus Torvalds wrote:
>
> On Sat, 6 Jan 2001, Adam J. Richter wrote:
> >
> > This sounds like a bug that I posted a fix for a long time ago.
> > cramfs calls bforget on the superblock area, destroying that block of
> > the ramdisk, even when the ramdisk does not contain a cramfs file system.
> > Normally, bforget is called on block that really can be trashed,
> > such as blocks release by truncate or unlink.
>
> I'd really prefer just not letting bforget() touch BH_Protected buffers.
> bforget() is also used by other things than unlink/truncate: it's used by
> various partition codes etc, and it's used by the raid logic.
Yup, I backed out Adam's one-liner in favor of the attached one-liner.
Tested on 2.4.0, but should patch cleanly to just about anything. ;-)
BTW Linus - you were of course right on the cramfs wanting 4096
blocksize... but without this fix, that doesn't matter much. ;-)
regards,
David
--
David L. Parsley
Network Administrator
Roanoke College
--- linux.linus/fs/buffer.c Wed Jan 3 23:45:26 2001
+++ linux/fs/buffer.c Wed Jan 10 15:49:36 2001
@@ -1145,13 +1145,15 @@
* free list if it can.. We can NOT free the buffer if:
* - there are other users of it
* - it is locked and thus can have active IO
+ * - it is marked BH_Protected
*/
void __bforget(struct buffer_head * buf)
{
/* grab the lru lock here to block bdflush. */
spin_lock(&lru_list_lock);
write_lock(&hash_table_lock);
- if (!atomic_dec_and_test(&buf->b_count) || buffer_locked(buf))
+ if (!atomic_dec_and_test(&buf->b_count) || buffer_locked(buf) ||
+ buffer_protected(buf))
goto in_use;
__hash_unlink(buf);
remove_inode_queue(buf);
question on generating a patch
I read the FAQ and SubmittingPatches, but how best to generate a patch that moves a file from on dir to another? diff -urNP makes the patch a lot longer than it seems like it should be... (fortunately it's just a short header file) Is there a better way? regards, David -- David L. Parsley Network Administrator Roanoke College - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch (repost): cramfs memory corruption fix
Alan Cox wrote: > -ac has the rather extended ramfs with resource limits and stuff. That one > also has rather more extended bugs 8). AFAIK none of those are in the vanilla > ramfs code Nifty stuff, too; it's nice for a ramfs mount to show up in 'df' with useful figures. Shame I can't put anything there. ;-) 2.4.0 ramfs with the one-liner does it's job for me already; what I'd really love to fool with is _cramfs_. ;-) In case you missed the beginning of this thread: all my cramfs initrd's fail to mount as /dev/ram0 with 'wrong magic'; their romfs counterparts work fine. I did manage to pivot_root into a cramfs root, but it blew up pretty quick with 'attempt to access beyond end of device', and killed my init shell. Then there's the wierdness where cramfs compiled in the kernel corrupts the romfs. Adam's one-liner (bforget -> brelse on superblock) didn't fix this. The cramfs docs are contradictory btw; the kernel help says 'doesn't support hardlinks', and Documentation/filesystems/cramfs.txt says 'Hardlinks are supported, but...'. I made my cramfs with and without hardlinks (to busybox); but that didn't affect whether it mounted. I haven't tested whether this fixes the 'access beyond end of device' problems. regards, David -- David L. Parsley Network Administrator Roanoke College - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
cramfs & ramfs problems in 2.4.0 up to ac3
Hi, Using root=/dev/ram0 and a cramfs initrd gives me 'wrong magic' when it tries to boot. Even more bizarre, if cramfs is compiled in the kernel when I use a romfs root, it says 'wrong magic' then mounts the romfs but can't find init. If I take cramfs out of the kernel, the romfs mounts & init runs fine. I just saw this with ac3. ramfs croaks with 'kernel BUG in filemap.c line 2559' anytime I make a file in ac2 and ac3. Works fine in 2.4.0 vanilla. Should be quite repeatable... BTW, nice work on 2.4 everyone. regards, David -- David L. Parsley Network Administrator Roanoke College - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
