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