Re: Cosmetic JFFS patch.
In article <[EMAIL PROTECTED]>, Chuck Wolber <[EMAIL PROTECTED]> wrote: >> Does sed tell you who programmed it on startup? >> >> Awk? >> >> Perl? >> >> Groff? >> >> Gcc? >> >> See a pattern here? > >Yeah, the output of these programms are usually parsed by other programs. >If they barked version info, that'd be extra code that has to go into >*EVERY* script that uses them. You're not using the kernel in the same >capacity. A counter example that does both, bc does tell us who wrote it every time we run it (most annoying) and is smart enough to know when it is not talking to a tty. % bc bc 1.05 Copyright 1991, 1992, 1993, 1994, 1997, 1998 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 1+2 3 % bc > test 1+2 % cat test 3 % I think listing driver versions on boot with perhaps some diagnostic info if appropriate is useful. Names and copyrights should be in the source. -- __O Lineo - For Embedded Linux Solutions _-\<,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne <[EMAIL PROTECTED]> www.fireplug.net604-461-7532 - 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: Cosmetic JFFS patch.
In article [EMAIL PROTECTED], Chuck Wolber [EMAIL PROTECTED] wrote: Does sed tell you who programmed it on startup? Awk? Perl? Groff? Gcc? See a pattern here? Yeah, the output of these programms are usually parsed by other programs. If they barked version info, that'd be extra code that has to go into *EVERY* script that uses them. You're not using the kernel in the same capacity. A counter example that does both, bc does tell us who wrote it every time we run it (most annoying) and is smart enough to know when it is not talking to a tty. % bc bc 1.05 Copyright 1991, 1992, 1993, 1994, 1997, 1998 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 1+2 3 % bc test 1+2 % cat test 3 % I think listing driver versions on boot with perhaps some diagnostic info if appropriate is useful. Names and copyrights should be in the source. -- __O Lineo - For Embedded Linux Solutions _-\,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne [EMAIL PROTECTED] www.fireplug.net604-461-7532 - 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 the best way for multiple net_devices
In article <[EMAIL PROTECTED]>, Jeff Garzik <[EMAIL PROTECTED]> wrote: >andrew may wrote: >> >> Is there a standard way to make multiple copies of a network device? >> >> For things like the bonding/ipip/ip_gre and others they seem to expect >> insmod -o copy1 module.o >> insmod -o copy2 module.o > >The network driver should provide the capability to add new devices. > >Most drivers currently have the capability to do N devices, where N is >some constant set at compile time. Typically you use ifconfig, a >special-purpose userland program, or sometimes even sysctls to configure >additional net devices. Ioctls require modifications to other parts of the kernel and a supporting user land program. Passing the number to create via insmod seems to be a reasonable compromise. >It's certainly possible to modify the driver to create additional >network interfaces on the fly, but a lot of drivers are not coded to do >that at present. -- __O Lineo - For Embedded Linux Solutions _-\<,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne <[EMAIL PROTECTED]> www.fireplug.net604-461-7532 - 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 the best way for multiple net_devices
In article [EMAIL PROTECTED], Jeff Garzik [EMAIL PROTECTED] wrote: andrew may wrote: Is there a standard way to make multiple copies of a network device? For things like the bonding/ipip/ip_gre and others they seem to expect insmod -o copy1 module.o insmod -o copy2 module.o The network driver should provide the capability to add new devices. Most drivers currently have the capability to do N devices, where N is some constant set at compile time. Typically you use ifconfig, a special-purpose userland program, or sometimes even sysctls to configure additional net devices. Ioctls require modifications to other parts of the kernel and a supporting user land program. Passing the number to create via insmod seems to be a reasonable compromise. It's certainly possible to modify the driver to create additional network interfaces on the fly, but a lot of drivers are not coded to do that at present. -- __O Lineo - For Embedded Linux Solutions _-\,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne [EMAIL PROTECTED] www.fireplug.net604-461-7532 - 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] Single user linux
In article <[EMAIL PROTECTED]>, Alan Cox <[EMAIL PROTECTED]> wrote: >> > Quit being a naysayer. UNIX on a PDA is a wet dream. >> What real value does it have, apart from the geek "look at me, I'm using >> bash" value? > >It means I can do anything on my ipaq I can do anywhere else. I can run >multiple apps at a time. I can run X11. I can run the palm emulator even ;) > >Its the same reason Linux is valuable on an S/390 mainframe. Its a common pool >of apps, environments and tools. Anything your PC can do, my ipaq can do. Or even if you only ever use the builtin apps on your Linux PDA, it means you didn't subsidize Microsoft. -- __O Lineo - For Embedded Linux Solutions _-\<,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne <[EMAIL PROTECTED]> www.fireplug.net604-461-7532 - 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] Single user linux
In article [EMAIL PROTECTED], Alan Cox [EMAIL PROTECTED] wrote: Quit being a naysayer. UNIX on a PDA is a wet dream. What real value does it have, apart from the geek look at me, I'm using bash value? It means I can do anything on my ipaq I can do anywhere else. I can run multiple apps at a time. I can run X11. I can run the palm emulator even ;) Its the same reason Linux is valuable on an S/390 mainframe. Its a common pool of apps, environments and tools. Anything your PC can do, my ipaq can do. Or even if you only ever use the builtin apps on your Linux PDA, it means you didn't subsidize Microsoft. -- __O Lineo - For Embedded Linux Solutions _-\,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne [EMAIL PROTECTED] www.fireplug.net604-461-7532 - 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: question \ information request on init \ boot sequence when using initrd
In article <[EMAIL PROTECTED]>,
Amit D Chaudhary <[EMAIL PROTECTED]> wrote:
>Hi,
>
>We(my team) had some questions regarding booting from initrd and using
>/linuxrc. It will help someone(David, Werner,...) can give their
>thoughts on this.
>
>To put it in brief, since running sbin/init from /linuxrc as resulting
>in init not having PID 1 and thereby not doing some initialization as
>expected.
>
>Thereby instead of loading running /sbin/init, we just set
>/proc/sys/kernel/real-root-dev to /dev/ram0's value which then does the
>following
>runs 2 statements in init/main.c to unlock_kernel and free init memory
>and then run sbin/init.
>This results in /sbin/init running fine.
>
>Is this ok or should be modify /sbin/init to run properly inspite of PID
><> 1 or is there a 3rd way of doing this?
>
>
>mkdir initrd
>../bin/pivot_root . initrd
>
>exec sbin/chroot . sbin/init.new 3 dev/console 2>&1
>
>
>The above results in init running with PID != 1 and thereby skipping
>some relevant processing my default. see ps output below:
>
>Instead of the "chroot" above is changed to following
>exec sbin/chroot . sh -c 'bin/mount proc proc -t proc; echo 0x0100 >
>proc/sys/kernel/real-root-dev'
>And linuxrc exits
>
>
>
>(none):root> ps -e
> PID TTY TIME CMD
> 1 ?00:00:04 swapper
> 2 ?00:00:00 keventd
> 3 ?00:00:00 kswapd
> 4 ?00:00:00 kreclaimd
> 5 ?00:00:00 bdflush
> 6 ?00:00:00 kupdate
> 7 ?00:00:00 mtdblockd
> 8 ?00:00:00 init
>26 ?00:00:00 sh
>39 ?00:00:00 portmap
>50 ?00:00:00 ypbind
>51 ?00:00:00 ypbind
>84 ?00:00:00 inetd
>93 ?00:00:00 syslogd
> 100 ?00:00:00 klogd
> 119 ?00:00:00 ps
You can run your linuxrc with:
init=/linuxrc
and then end your /linuxrc with:
exec /sbin/init
--
__O
Lineo - For Embedded Linux Solutions _-\<,_
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <[EMAIL PROTECTED]> www.fireplug.net604-461-7532
-
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: question \ information request on init \ boot sequence when using initrd
In article [EMAIL PROTECTED], Amit D Chaudhary [EMAIL PROTECTED] wrote: Hi, We(my team) had some questions regarding booting from initrd and using /linuxrc. It will help someone(David, Werner,...) can give their thoughts on this. To put it in brief, since running sbin/init from /linuxrc as resulting in init not having PID 1 and thereby not doing some initialization as expected. Thereby instead of loading running /sbin/init, we just set /proc/sys/kernel/real-root-dev to /dev/ram0's value which then does the following runs 2 statements in init/main.c to unlock_kernel and free init memory and then run sbin/init. This results in /sbin/init running fine. Is this ok or should be modify /sbin/init to run properly inspite of PID 1 or is there a 3rd way of doing this? mkdir initrd ../bin/pivot_root . initrd exec sbin/chroot . sbin/init.new 3 dev/console dev/console 21 The above results in init running with PID != 1 and thereby skipping some relevant processing my default. see ps output below: Instead of the "chroot" above is changed to following exec sbin/chroot . sh -c 'bin/mount proc proc -t proc; echo 0x0100 proc/sys/kernel/real-root-dev' And linuxrc exits (none):root ps -e PID TTY TIME CMD 1 ?00:00:04 swapper 2 ?00:00:00 keventd 3 ?00:00:00 kswapd 4 ?00:00:00 kreclaimd 5 ?00:00:00 bdflush 6 ?00:00:00 kupdate 7 ?00:00:00 mtdblockd 8 ?00:00:00 init 26 ?00:00:00 sh 39 ?00:00:00 portmap 50 ?00:00:00 ypbind 51 ?00:00:00 ypbind 84 ?00:00:00 inetd 93 ?00:00:00 syslogd 100 ?00:00:00 klogd 119 ?00:00:00 ps You can run your linuxrc with: init=/linuxrc and then end your /linuxrc with: exec /sbin/init -- __O Lineo - For Embedded Linux Solutions _-\,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne [EMAIL PROTECTED] www.fireplug.net604-461-7532 - 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: /linuxrc query
In article <[EMAIL PROTECTED]>, David Woodhouse <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] said: >> Also as a note, what we are doing is keeping our rootfs on flash as a >> tar.gz and reading it and mounting it on a ramfs in the /linuxrc >> before doing a pivot_root. To summarize, pivot_root has been a life >> saver as the earlier real_root_dev might not have been useful in this >> case. Not using the ramfs limits for now, will do soon. > >If you're concerned about memory usage - why untar the whole of your root >filesystem into a ramfs? My preferred solution is to just mount the root >filesystem directly from the flash as cramfs (or JFFS2), with symlinks into a >ramfs for appropriate parts like /tmp and /var. > >I suppose the best option is actually to union-mount the ramfs over the >root, rather than mucking about with symlinks. I just haven't got round to >doing that yet. Union would be fine. But until then I prefer ramfs as root with symlinks to cramfs for anything that doesn't need to be writeable. -- __O Lineo - For Embedded Linux Solutions _-\<,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne <[EMAIL PROTECTED]> www.fireplug.net604-461-7532 - 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: /linuxrc query
In article [EMAIL PROTECTED], David Woodhouse [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] said: Also as a note, what we are doing is keeping our rootfs on flash as a tar.gz and reading it and mounting it on a ramfs in the /linuxrc before doing a pivot_root. To summarize, pivot_root has been a life saver as the earlier real_root_dev might not have been useful in this case. Not using the ramfs limits for now, will do soon. If you're concerned about memory usage - why untar the whole of your root filesystem into a ramfs? My preferred solution is to just mount the root filesystem directly from the flash as cramfs (or JFFS2), with symlinks into a ramfs for appropriate parts like /tmp and /var. I suppose the best option is actually to union-mount the ramfs over the root, rather than mucking about with symlinks. I just haven't got round to doing that yet. Union would be fine. But until then I prefer ramfs as root with symlinks to cramfs for anything that doesn't need to be writeable. -- __O Lineo - For Embedded Linux Solutions _-\,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne [EMAIL PROTECTED] www.fireplug.net604-461-7532 - 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: hotmail not dealing with ECN
In article <[EMAIL PROTECTED]>, James Sutherland <[EMAIL PROTECTED]> wrote: >On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote: >Except you can't retry without ECN, because DaveM wants to do a Microsoft >and force ECN on everyone, whether they like it or not. If ECN is so No, he just wants them to ignore it like they are supposed to do if they don't know what it is. >wonderful, why doesn't anybody actually WANT to use it anyway? Because they are stupid and don't want to take the time and energy to upgrade their systems. Most ISP's have the generic rule, if it ain't broke, don't fuck with it. Even the mighty microsoft learned just two days ago what happens if you make mistakes changing routing information. -- __O Lineo - For Emedded Linux Solutions _-\<,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne <[EMAIL PROTECTED]> www.fireplug.net604-461-7532 - 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: hotmail not dealing with ECN
In article [EMAIL PROTECTED], James Sutherland [EMAIL PROTECTED] wrote: On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote: Except you can't retry without ECN, because DaveM wants to do a Microsoft and force ECN on everyone, whether they like it or not. If ECN is so No, he just wants them to ignore it like they are supposed to do if they don't know what it is. wonderful, why doesn't anybody actually WANT to use it anyway? Because they are stupid and don't want to take the time and energy to upgrade their systems. Most ISP's have the generic rule, if it ain't broke, don't fuck with it. Even the mighty microsoft learned just two days ago what happens if you make mistakes changing routing information. -- __O Lineo - For Emedded Linux Solutions _-\,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne [EMAIL PROTECTED] www.fireplug.net604-461-7532 - 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: [RFC-2] Configuring Synchronous Interfaces in Linux
On Tue, Dec 05, 2000 at 05:34:50PM -0800, Dan Hollis wrote: > On Wed, 6 Dec 2000, Alan Cox wrote: > > > Ditto, we have an adsl driver that we setup by overloading various otherwise > > > unused options in ifconfig (mem_start, io_addr etc) to do this. Cheaper and > > > faster than writing yet another ioctl using device configuration agent, but > > > distasteful non the less. > > Generic is not always good , thats why we have SIOCDEVPRIVATE. One thing Im > > pondering is if we should make the hardware config ioctl take a hardware type > > ident with each struct. That would help make all the ethernet agree, all the > > wan agree, all the ADSL agree without making a nasty mess. > > Id be up for that, but its hard to standardize on IOCTLs without people > publishing their drivers, as long as people hide their code we dont know > what everyone else is doing config interface wise... > > Lets see the code, people... We are trying to get permission from the customer to release it. -- __O Fireplug - a Lineo company_-\<,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne <[EMAIL PROTECTED]> www.lineo.com 604-461-7532 - 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: [RFC-2] Configuring Synchronous Interfaces in Linux
> > I have a vested interest in how this all turns out. I own a Packet Over SONET > device driver for our OC-12 and OC-48 NICs that I currently pass all parameters > to the driver via arguments on the insmod. To avoid lengthy commands, we > provide the common defaults. We accept some basic ifconfig input, but with > SONET/SDH and chip specific items that needed to be controlled, ifconfig did not > seem the way to go. Ditto, we have an adsl driver that we setup by overloading various otherwise unused options in ifconfig (mem_start, io_addr etc) to do this. Cheaper and faster than writing yet another ioctl using device configuration agent, but distasteful non the less. Some generic way to pass configuration data using a generic configuration agent to network (and other) drivers would be interesting. > > > I'm willing to go for this implementation, but I wanted to know first: > > > - whether ifconfig is the right place to do it; > > > - where I should create the new ioctl's to handle these new parameters. > > > > I think a new ioctl would be sensible. There is a lot to go in it. -- __O Fireplug - a Lineo company_-\<,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne <[EMAIL PROTECTED]> www.lineo.com 604-461-7532 - 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: [RFC-2] Configuring Synchronous Interfaces in Linux
I have a vested interest in how this all turns out. I own a Packet Over SONET device driver for our OC-12 and OC-48 NICs that I currently pass all parameters to the driver via arguments on the insmod. To avoid lengthy commands, we provide the common defaults. We accept some basic ifconfig input, but with SONET/SDH and chip specific items that needed to be controlled, ifconfig did not seem the way to go. Ditto, we have an adsl driver that we setup by overloading various otherwise unused options in ifconfig (mem_start, io_addr etc) to do this. Cheaper and faster than writing yet another ioctl using device configuration agent, but distasteful non the less. Some generic way to pass configuration data using a generic configuration agent to network (and other) drivers would be interesting. I'm willing to go for this implementation, but I wanted to know first: - whether ifconfig is the right place to do it; - where I should create the new ioctl's to handle these new parameters. I think a new ioctl would be sensible. There is a lot to go in it. -- __O Fireplug - a Lineo company_-\,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne [EMAIL PROTECTED] www.lineo.com 604-461-7532 - 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: [RFC-2] Configuring Synchronous Interfaces in Linux
On Tue, Dec 05, 2000 at 05:34:50PM -0800, Dan Hollis wrote: On Wed, 6 Dec 2000, Alan Cox wrote: Ditto, we have an adsl driver that we setup by overloading various otherwise unused options in ifconfig (mem_start, io_addr etc) to do this. Cheaper and faster than writing yet another ioctl using device configuration agent, but distasteful non the less. Generic is not always good , thats why we have SIOCDEVPRIVATE. One thing Im pondering is if we should make the hardware config ioctl take a hardware type ident with each struct. That would help make all the ethernet agree, all the wan agree, all the ADSL agree without making a nasty mess. Id be up for that, but its hard to standardize on IOCTLs without people publishing their drivers, as long as people hide their code we dont know what everyone else is doing config interface wise... Lets see the code, people... We are trying to get permission from the customer to release it. -- __O Fireplug - a Lineo company_-\,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne [EMAIL PROTECTED] www.lineo.com 604-461-7532 - 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: / on ramfs, possible?
In article <[EMAIL PROTECTED]>, Anders Eriksson <[EMAIL PROTECTED]> wrote: >--==_Exmh_17293564P >Content-Type: text/plain; charset=us-ascii > > >I want my / to be a ramfs filesystem. I intend to populate it from an >initrd image, and then remount / as the ramfs filesystem. Is that at >all possible? The way I see it the kernel requires / on a device >(major,minor) or nfs. > >Am I out of luck using ramfs as /? If it's easy to fix, how do I fix it? Yes it works. You will need pivot_root. Something like the following at the end of your initrd /linuxrc script should mount your ramfs, copy the existing root fs files to it, pivot and unmount your old root. YMMV mkdir -p /ramfs /ram1 mount -t ramfs /ramfs /ramfs find / | sed '/^\/ramfs/d;/^\/proc\/.*/d' | cpio -pdmV /ramfs cd /ramfs pivot_root . ram1 exec chroot . sh -c 'umount /ram1; exit' < dev/console >dev/console BTW has anyone thought of writing a small utility to emulate df for ramfs? -- __O Fireplug - a Lineo company_-\<,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne <[EMAIL PROTECTED]> www.fireplug.net604-461-7532 - 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: Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE
You can ran into problems using schedule_timeout() in a block device request function under 2.4. This can be demonstrated by starting some I/O intensive tasks to your block device and running sync in another task. Eventually the block layer will lock up. This can be fixed by creating a kernel thread per flash device to handle the I/O requests. Within the thread schedule_timeout() works fine. This solution also works under 2.2 and 2.0.38 [EMAIL PROTECTED] (David Woodhouse) said: > [EMAIL PROTECTED] said: > > So it seems to be a bug at least in terms of timing. Unfortunately I > > only got about 4 replies to the patches that touched 20+ drivers. I > > suppose I should just hassle maintainers until they fix it or tell me > > where I've gone wrong ... > > Actually, I was quite happy calling schedule_timeout in the flash drivers > without changing current->state. I'm waiting to something to happen, and > just to be considerate, I'm asking to be put to sleep for the 'expected' > amount of time for whatever's happening. If there's other stuff on the run > queue, it won't return immediately, will it? If there isn't other stuff on > the run queue, I'll just busy wait till the flash chip's finished. > > Otherwise, it would be TASK_UNINTERRUPTIBLE. -- __O Fireplug - a Lineo company_-\<,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne <[EMAIL PROTECTED]> www.lineo.com 604-461-7532 - 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: Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE
You can ran into problems using schedule_timeout() in a block device request function under 2.4. This can be demonstrated by starting some I/O intensive tasks to your block device and running sync in another task. Eventually the block layer will lock up. This can be fixed by creating a kernel thread per flash device to handle the I/O requests. Within the thread schedule_timeout() works fine. This solution also works under 2.2 and 2.0.38 [EMAIL PROTECTED] (David Woodhouse) said: [EMAIL PROTECTED] said: So it seems to be a bug at least in terms of timing. Unfortunately I only got about 4 replies to the patches that touched 20+ drivers. I suppose I should just hassle maintainers until they fix it or tell me where I've gone wrong ... Actually, I was quite happy calling schedule_timeout in the flash drivers without changing current-state. I'm waiting to something to happen, and just to be considerate, I'm asking to be put to sleep for the 'expected' amount of time for whatever's happening. If there's other stuff on the run queue, it won't return immediately, will it? If there isn't other stuff on the run queue, I'll just busy wait till the flash chip's finished. Otherwise, it would be TASK_UNINTERRUPTIBLE. -- __O Fireplug - a Lineo company_-\,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne [EMAIL PROTECTED] www.lineo.com 604-461-7532 - 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: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
In article <[EMAIL PROTECTED]>, Andre Hedrick <[EMAIL PROTECTED]> wrote: >Hans, > >We talked at LWE '99 about this issue. >As you can see that this is getting to be a bigger mess as I predicted >more than a year ago. As you explained to me that IGEL had verbal terms >of agreement that the code returned to M-Systems was returned with a GPL >license in it placed by IGEL. M-Systems then remove the GPL license and >converted the code in to an object that violated the rules and spirit of >GPL. M-Systems distributes something that is perfectly legal for an end user to use. Nothing prevents someone from linking anything they want into their own copy of a kernel they will use themselves. Unfortunately there was no easy way for anyone who wanted to distribute a product with a DOC to distribute a kernel. M-Systems is in the process of creating a new driver that works as a module and contains no GPL code. -- __O Fireplug - a Lineo company_-\<,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne <[EMAIL PROTECTED]> www.fireplug.net604-461-7532 - 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: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
In article [EMAIL PROTECTED], Andre Hedrick [EMAIL PROTECTED] wrote: Hans, We talked at LWE '99 about this issue. As you can see that this is getting to be a bigger mess as I predicted more than a year ago. As you explained to me that IGEL had verbal terms of agreement that the code returned to M-Systems was returned with a GPL license in it placed by IGEL. M-Systems then remove the GPL license and converted the code in to an object that violated the rules and spirit of GPL. M-Systems distributes something that is perfectly legal for an end user to use. Nothing prevents someone from linking anything they want into their own copy of a kernel they will use themselves. Unfortunately there was no easy way for anyone who wanted to distribute a product with a DOC to distribute a kernel. M-Systems is in the process of creating a new driver that works as a module and contains no GPL code. -- __O Fireplug - a Lineo company_-\,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne [EMAIL PROTECTED] www.fireplug.net604-461-7532 - 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: If loadable modules are covered by Linux GPL?
In article <[EMAIL PROTECTED]>, Simon Richter <[EMAIL PROTECTED]> wrote: >On Tue, 29 Aug 2000, Mike A. Harris wrote: > >> #include'ing header files is not necessarily ok. Some headers >> include "inline functions" which is GPL code. Such inclusion in >> a module makes that module have to comply with GPL. > >I think this needs to be resolved ASAP. I don't have kernel sources handy, >so I cannot tell you whether the functions are actually worth being >protected (inb/outb doesn't belong to this group really), If it is in the header file I think it should be open for use. Not allowing inline code to be used just adds another hoop to jump. Just compile with that function explicitly defined. Define another version in the kernel and use that in your module instead. Etc. There was another thread a few days ago commenting that modern processors may actually be a bit faster with less inlined code and unrolled loops. Which may mean that a lot of what is now inlined may be better off compiled in. -- __O Fireplug - a Lineo company_-\<,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne <[EMAIL PROTECTED]> www.fireplug.net604-461-7532 - 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/
