Re: 1GB system working with 64MB
Add this: append="mem=1024M" to your lilo boot profiles. ... 2.4 correctly detects memory size more often than 2.2.16 ... - Original Message - From: "Edouard Soriano" <[EMAIL PROTECTED]> Subject: 1GB system working with 64MB > Hello Folks, > Environment: linux 2.2.16smp > RedHat 7.0 > > My problem are the 63892K - 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: Uncle Sam Wants YOU!
I re-subscribed for this? Blarg. When did the LKML turn into slashdot? On 01 Jul 2001 17:33:38 -0700, Ted Unangst wrote: > On Sun, 1 Jul 2001, Ben Ford wrote: > > > Name a single tech company anywhere in the world that doesn't have to > > deal with microsoftisms. > > http://www.wasabisystems.com/ > > > Well, when you realize that Bill Gates (not MS, just Bill Gates > > personally) has enough money to give every person in the world $10 out > > of his pocket, then you see this argument in a different light. > > that's called capitalism. > > ted > > -- > "First, it was not a strip bar, it was an erotic club. And second, > what can I say? I'm a night owl." > - M. Barry, Mayor of Washington, DC > > - > 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/ -- Michael Rothwell [EMAIL PROTECTED] - 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: Soft updates for 2.5?
While on the topic of reslilent, high-performance filesystems, what ever became of "Tux", Daniel Philip's mythical WAFL-type filesystem? On 01 Jul 2001 23:33:52 -0300, Rik van Riel wrote: > On Sat, 30 Jun 2001, Alex Khripin wrote: > > > There was a discussion in October, 2000, about the Granger and > > McKusick paper on soft updates for the BSD FFS. Reading the thread, > > nothing conclusive seemed to come out of it. > > What you want is ext3. > > It is a journaling version of ext2, which basically > means you get all the advantages of soft updates and > a bit more (due to the atomicity that journaled > transactions can give you). > > It should be superior to softupdates in both the > consistency area and the performance area (due to > the fact that stuff is in the journal, you have > more freedom to reorder the writes to the "main" > part of the filesystem). > > regards, > > Rik > -- > Virtual memory is like a game you can't win; > However, without VM there's truly nothing to lose... > > http://www.surriel.com/ http://distro.conectiva.com/ > > Send all your spam to [EMAIL PROTECTED] (spam digging piggy) > > - > 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/ -- Michael Rothwell [EMAIL PROTECTED] - 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: Alan Cox quote? (was: Re: accounting for threads)
On 20 Jun 2001 10:14:48 +0100, Alan Cox wrote: > It does. ... not > They are always readable. That's not very useful. Not in the sense of supporting aync, non-blocking i/o to disk files without using threads. -- Michael Rothwell [EMAIL PROTECTED] - 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: Alan Cox quote? (was: Re: accounting for threads)
On 19 Jun 2001 20:01:56 +0100, Alan Cox wrote: > Linux inherits several unix properties which are not friendly to good state > based programming - lack of good AIO for one. Oh, how I would love for select() and poll() to work on files... or for any other working AIO mothods to be present. What would get broken if things were changed to let select() work for filesystem fds? - 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: threading question
Try this:
http://lecker.essen.de/~froese/coro/
-M
On 16 Jun 2001 14:33:50 -0400, Russell Leighton wrote:
>
> Is there a user-space implemenation (library?) for coroutines that would work from C?
>
>
> Alan Cox wrote:
>
> > > Can you provide any info and/or examples of co-routines? I'm curious to
> > > see a good example of co-routines' "betterness."
> >
> > With co-routines you don't need
> >
> > 8K of kernel stack
> > Scheduler overhead
> > Fancy locking
> >
> > You don't get the automatic thread switching stuff though.
> >
> > So you might get code that reads like this (note that aio_ stuff works rather
> > well combined with co-routines as it fixes a lack of asynchronicity in the
> > unix disk I/O world)
> >
> > select()
> >
> > if(FD_ISSET(copier_fd))
> > run_coroutine(&copier_state);
> >
> > ...
> >
> > and the copier might be something like
> >
> > while(1)
> > {
> > // Yes 1 at a time is dumb but this is an example..
> > // Yes Im ignoring EOF for this
> > if(read(copier_fd, buf[bufptr], 1)==-1)
> > {
> > if(errno==-EWOULDBLOCK)
> > {
> > coroutine_return();
> > continue;
> > }
> > }
> > if(bufptr==255 || buf[bufptr]=='\n')
> > {
> > run_coroutine(run_command, buf);
> > bufptr=0;
> > }
> > else
> > bufptr++;
> > }
> >
> > it lets you express a state machine as a set of multiple such small state
> > machines instead. run_coroutine() will continue a routine where it last
> > coroutine_return()'d from. Thus in the above case we are expressing read
> > bytes until you see a new line cleanly - not mangled in with keeping state
> > in global structures but by using natural C local variables and code flow
> >
> > Alan
> >
> > -
> > 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/
>
> --
> ---
> Russell Leighton[EMAIL PROTECTED]
> ---
>
>
> -
> 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/
--
Michael Rothwell
[EMAIL PROTECTED]
-
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: ps2 keyboard filter hook
On 15 Jun 2001 16:03:32 -0400, [EMAIL PROTECTED] wrote: > > IBM Retail Store Solutions dept has certain PS/2 keyboards which extend the > standard PS/2 specification in order to support addition hardware built into the > keyboard (such as a Magnetic Strip Reader, Keylock, Tone generator, extra keys, > -Dan I'm facing a similar problem with the "Qoder" barcode scanner. I have to have a keyboard hook. The "right" way seem to be to use the input api. Unfortunately, this means that current kernels can't use the driver w/o a patch (the input api patch). The ugly way is to patch the keyboard driver. I'm doing both. However, I wrote a REALLY SIMPLE hook tht supported exactly my needs, since it's in the category of "ugly hack waiting for input api." Maybe I'll write a version for your hook. I wonder when the input api stuff for ps/2 devices will be a part of the mainstream kernel... -- Michael Rothwell [EMAIL PROTECTED] - 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: keyboard hook?
Thanks, I'm loking through your driver now. Does the input api already/currently support ps2 keyboards? -M On Sat, Jun 02, 2001 at 08:40:04PM -0700, James Simmons wrote: > > Hi! > >Your best bet for a kernel driver is to use the linux input api like > the usb keyboard do. The drivers are pretty simple to write and since all > the keyboard drivers will be port over to this api it will save a lot of > work done the road. If you need help let me know. I will be glad to help. > It sounds alot alike the p2 to serial driver just placed in our CVS. You > can access our CVS by doing > > cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/linuxconsole login > > cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/linuxconsole >co ruby > > The driver is in ruby/linux/drivers/input as ps2serkbd.c. > > > I'm beginning the process of writing a driver for the "Qoder" > > keyboard-fob barcode scanner made by InterMec. It communicates with the > > host computer using the PS/2 port by way of a "dock" that sits in > > between the keyboard and the computer. > > > One of them is "turn > > numlock light on," which I can do with an ioctl from userspace (as root, > > anyway), but also caps lock, num lock and carriage-return scancodes. > > EV_LED > > > The CueCat driver written by Pierre Coupard also modifies the keyboard > > driver. It would be nice if it was possible to load modules that hook > > into keyboard processing without requiring a kernel patch. And perhaps > > there is, but I haven't run across it yet. > > input api :-) > - 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: keyboard hook?
Input API looks nice. For now, I'll write a patch against pc_keyb.c to add a hook for my qoder stuff, and a loadable module for the meat of the driver. Then I'll port up to the input API. The Qoder is strictly ps/2 keyboard, as far as its interface goes, so I cannot use the input API for now. I have a Sparc here; does it have drivers you wish to have ported? On Sun, Jun 03, 2001 at 09:02:18PM -0700, James Simmons wrote: > > > Thanks, I'm loking through your driver now. Does the input api > > already/currently support ps2 keyboards? > > With the current tree no. The work around is to make input api keyboards > behave as PS/2 keyboards. In 2.5.X ps2 keyboards will be input api based. > As you can see we already have PS/2 input api driver (i8042.c and atkbd.c). > I have been using it for several months now. It is just a matter of making > sure it works on other platforms besides intel. > > P.S >I also need to port other keyboard drivers on other platforms over to > the input api and test these drivers. If anyone would like to help out > contact me. - 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/
keyboard hook?
I'm beginning the process of writing a driver for the "Qoder"
keyboard-fob barcode scanner made by InterMec. It communicates with the
host computer using the PS/2 port by way of a "dock" that sits in
between the keyboard and the computer.
The dock does handshaking with the host computer, which means that it
listens for specific signals sent from the host. One of them is "turn
numlock light on," which I can do with an ioctl from userspace (as root,
anyway), but also caps lock, num lock and carriage-return scancodes.
I will have to modify the keyboard driver to capture and process data
from the barcode scanner cleanly, and without requiring root access for
the client programs.
The CueCat driver written by Pierre Coupard also modifies the keyboard
driver. It would be nice if it was possible to load modules that hook
into keyboard processing without requiring a kernel patch. And perhaps
there is, but I haven't run across it yet.
I just need to scan the keystroke stream for an attention signal
(shift,shift,shift,alt,ctrl) and then respond ("turn on numlock light")
to initiate the data transfer; then, of course, capture and format that
data and make it available via /proc, or something.
Does anyone have any suggestions before I go ugly-up the keyboard
driver?
Thanks,
--
Michael Rothwell
[EMAIL PROTECTED]
-
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/
OOPS - 2.2.19, USB, Scanner
Just your friendly neighborhood oops report. Unfortunately, the kernel didn't log very much: May 14 18:00:49 gateway kernel: scanner.c: read_scanner(0): funky result:-32. Please notify the maintainer. May 14 18:01:13 gateway PAM_pwdb[10338]: (login) session opened for user rothwell by (uid=0) May 14 18:01:21 gateway PAM_pwdb[10364]: (su) session opened for user root by rothwell(uid=500) May 14 18:01:46 gateway kernel: usb.c: USB disconnect on device 2 May 14 18:02:00 gateway kernel: usb.c: USB new device connect, assigned device number 2 May 14 18:02:09 gateway kernel: usb.c: deregistering driver ibmcam May 14 18:02:09 gateway kernel: usb.c: USB disconnect on device 1 May 14 18:02:09 gateway kernel: usb.c: USB disconnect on device 2 May 14 18:02:09 gateway kernel: usb.c: USB bus 1 deregistered May 14 18:02:09 gateway kernel: kmem_destroy: Can't free all objects c7fffb00 May 14 18:02:09 gateway kernel: uhci: not all urb_priv's were freed May 14 18:02:09 gateway kernel: kmem_destroy: Can't free all objects c7fffaa0 May 14 18:02:09 gateway kernel: uhci: not all QH's were freed May 14 18:02:09 gateway kernel: kmem_destroy: Can't free all objects c7fffa40 May 14 18:02:09 gateway kernel: uhci: not all TD's were freed May 14 18:02:30 gateway kernel: usb_control/bulk_msg: timeout May 14 18:02:30 gateway kernel: Unable to handle kernel paging request at virtual address c886f350 May 14 18:02:30 gateway kernel: current->tss.cr3 = 00101000, %%cr3 = 00101000 May 14 18:02:30 gateway kernel: *pde = 07ffa063 May 14 18:02:30 gateway kernel: *pte = May 14 18:02:30 gateway kernel: Oops: May 14 18:02:30 gateway kernel: CPU:0 ... the scanner appeared to hang while using SANE. I attempted to rmmod the usb modules, including scanner.o, and uhci.o. Oops. -M - 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: Linux syscall speed -- was X15 rootin-tootin webserver
There seems to be a contingent of people on the LKML who think that it is appropriate to flame people off-list, in order to bask in their own superiority, or prove that they are smarter by pointing out that someone is an idiot, etc. I would figure that most intelligent people would simply ignore posts they don't like, rather than investing time and bandwidth compounding the perceived offense. But I'm apparently too optimistic on that point; any group of people the size of the LKML will always contain some juviniles. A great many of us have suffered their attention. -M On 04 May 2001 11:21:48 +1000, Rusty Russell wrote: > In message <988856961.6355.1.camel@gromit> you write: > > According to tests performed at IBM: > > > > http://www-106.ibm.com/developerworks/linux/library/l-rt1/ > > > > Linux's sycalls are a little more than twice as fast as those of Windows > > This post was pretty much a waste of space, wasn't it? > > > 2000. 0.75usec vs 2.0msec. > > That would be 2,666 times. > > Rusty. > -- > Premature optmztion is rt of all evl. --DK - 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/
Linux syscall speed -- was X15 rootin-tootin webserver
According to tests performed at IBM: http://www-106.ibm.com/developerworks/linux/library/l-rt1/ Linux's sycalls are a little more than twice as fast as those of Windows 2000. 0.75usec vs 2.0msec. Not too shabby. And this "magic page" idea means it may get faster. -M - 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: Common GUI Config for All Users
To whom are you referring? -M On 30 Apr 2001 10:11:04 -0600, [EMAIL PROTECTED] wrote: > Thank you for the =constructive= answer Mohammad. I have thusfar only received >criticism for my question, with no further information, which I think is destructive >to the spirit of the list, and to the culture. > > Those who act like pricks toward newcomers should be treated as such, and I will >remember them. > -- > C. > > The best way out is always through. > - Robert Frost A Servant to Servants, 1914 > > > "Mohammad A. Haque" wrote: > > > On Mon, 30 Apr 2001 [EMAIL PROTECTED] wrote: > > > > > Looking for the best way to give all users a common desktop, which comes from >one source (for easy administration). > > > > This list doesn't deal with what you are asking. Try > > http://www.linux.com and see if anything/anyone there can help you. > > > > -- > > > > = > > Mohammad A. Haque http://www.haque.net/ > >[EMAIL PROTECTED] > > > > "Alcohol and calculus don't mix. Project Lead > >Don't drink and derive." --Unknown http://wm.themes.org/ > >[EMAIL PROTECTED] > > = > > > > > - > 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/ - 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: #define HZ 1024 -- negative effects?
Great. I'm running 4.02. How do I enable "silken mouse"? Thanks, -Michael On 29 Apr 2001 14:44:11 -0700, Jim Gettys wrote: > The biggest single issue in GUI responsiveness on Linux has been caused > by XFree86's implementation of mouse tracking in user space. > > On typical UNIX systems, the mouse was often controlled in the kernel > driver. Until recently (XFree86 4.0 days), the XFree86 server's reads > of mouse/keyboard events were not signal driven, so that if the X server > was loaded, the cursor stopped moving. > > On most (but not all) current XFree86 implementations, this is now > signal drive, and further the internal X schedular has been reworked to > make it difficult for a single client to monopolize the X server. > > So the first thing you should try is to make sure you are using an X server > with this "silken mouse" enabled; anotherwords, run XFree86 4.0x and make > sure the implementation has it enabled > > There may be more to do in Linux thereafter, but until you've done this, you > don't get to discuss the matter further > - Jim Gettys > > -- > Jim Gettys > Technology and Corporate Development > Compaq Computer Corporation > [EMAIL PROTECTED] > > - > 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/ - 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: Sony Memory stick format funnies...
From: "H. Peter Anvin" <[EMAIL PROTECTED]> > "dcim" probably stands for "digital camera images". At least Canon > digital cameras always put their data in a directory named dcim. Makes sense. FAT's root directory is limited in the number of entries it can contain, to something like 32. Cameras can easily produce more than that number of images. -M - 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: Common GUI Config for All Users
Hmmm... this is the kernel list... not only the wrong place to ask UI questions, but lots of people here don't even like UIs. :) http://www.gnome.org -M - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, April 28, 2001 2:13 PM Subject: Common GUI Config for All Users > Looking for the best way to give all users a common desktop, which comes from one source (for easy administration). > > Found copying my /root/.gnome & .sawfish directories to a user home breaks the user's GUI, implying a symlink wouldn't work. I am told .gnome & .sawfish can be copied to /etc/skel to give common look for new users, but need ongoing single-source control. Besides, I tried copying root's config files to skel & it broke user GUIs. > > Security is also a concern, so couldn't symlink into root anyway. > > Recommendations welcomed, please. > -- > C. > > The best way out is always through. > - Robert Frost A Servant to Servants, 1914 > > > - > 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/ > - 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: #define HZ 1024 -- negative effects
Well, for kicks, I tried setting HZ to 1024 with 2.2.19. It seemed a
little more responsive, but that could be psychosomatic. :) I did notice
that I was unable to sync my palm pilot until I set it back to 100.
YMMV. The most useful "performace" tweak for a GUI that I've come across is:
#define _SHM_ID_BITS10
... if y ou're running Gnome and/or Gtk, because of its appetite for
lots of SHM segments.
-Michael
Mark Hahn wrote:
>>> Are there any negative effects of editing include/asm/param.h to change
>>> HZ from 100 to 1024? Or any other number? This has been suggested as a
>>> way to improve the responsiveness of the GUI on a Linux system. Does it
>>
> ...
>
>> Why not just run the X server at a realtime priority? Then it will get
>> to respond to existing events, such as keyboard and mouse input,
>> promptly without creating lots of superfluous extra clock interrupts.
>> I think you will find this is a better solution.
>
>
> it's surprisingly ineffective; usually, if someone thinks responsiveness
> is bad, there's a problem with the system. for instance, if the system
> is swapping, setting X (and wm, and clients) to RT makes little difference,
> since the kernel is stealing pages from them, regardless of their scheduling
> priority.
>
> if you're curious, you might be interested in two toy programs
> I've attached. one is "setrealtime", which will make a pid RT, or else act
> as a wrapper (ala /bin/time). I have it installed suid root on my system,
> though this is rather dangerous if your have lusers around. the second is a
> simple memory-hog: mmaps a bunch of ram, and keeps it active (printing out a
> handy measure of how long it took to touch its pages...)
>
> regards, mark hahn.
>
>
>
>
> #include
> #include
> #include
> #include
> #include
>
> volatile unsigned sink;
>
> double second() {
> struct timeval tv;
> gettimeofday(&tv,0);
> return tv.tv_sec + 1e-6 * tv.tv_usec;
> }
>
> int
> main(int argc, char *argv[]) {
> int doWrite = 1;
> unsigned size = 80 * 1024 * 1024;
>
> int letter;
> while ((letter = getopt(argc, argv, "s:wrvh?" )) != -1) {
> switch(letter) {
> case 's': size = atoi(optarg) * 1024 * 1024; break;
> case 'w': doWrite = 1; break;
> default:
> fprintf(stderr,"useup [-s mb][-w]\n");
> exit(1);
> }
> }
> int *base = (int*) mmap(0, size,
> PROT_READ|PROT_WRITE,
> MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);
> if (base == MAP_FAILED) {
> perror("mmap failed");
> exit(1);
> }
>
> int *end = base + size/4;
>
> while (1) {
> double start = second();
> if (doWrite)
> for (int *p = base; p < end; p += 1024)
> *p = 0;
> else {
> unsigned sum = 0;
> for (int *p = base; p < end; p += 1024)
> sum += *p;
> sink = sum;
> }
> printf("%f\n",1000*(second() - start));
> }
> }
>
>
>
>
> #include
> #include
> #include
> #include
>
> int
> main(int argc, char *argv[]) {
> int uid = getuid();
> int pid = atoi(argv[1]);
> int sched_fifo_min, sched_fifo_max;
> static struct sched_param sched_parms;
>
> if (!pid)
> pid = getpid();
>
> sched_fifo_min = sched_get_priority_min(SCHED_FIFO);
> sched_fifo_max = sched_get_priority_max(SCHED_FIFO);
> sched_parms.sched_priority = sched_fifo_min + 1;
>
> if (sched_setscheduler(pid, SCHED_FIFO, &sched_parms) == -1)
> perror("cannot set realtime scheduling policy");
>
> if (uid)
> setuid(uid);
>
> if (pid == getpid())
> execvp(argv[1],&argv[1]);
> return 0;
> }
> useup.c
>
> Content-Description:
>
> useup.c
> Content-Type:
>
> TEXT/PLAIN
> Content-Encoding:
>
> BASE64
>
>
>
> setrealtime.c
>
> Content-Description:
>
> setrealtime.c
> Content-Type:
>
> TEXT/PLAIN
> Content-Encoding:
>
> BASE64
>
>
-
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/
#define HZ 1024 -- negative effects?
Are there any negative effects of editing include/asm/param.h to change HZ from 100 to 1024? Or any other number? This has been suggested as a way to improve the responsiveness of the GUI on a Linux system. Does it throw off anything else, like serial port timing, etc.? - 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/
usb insmod hang w/2.4.2
I'm installing Linux onto a Compaq iPaq IA-1 -- the little "MSN
Companion" thing. I wish Compaq didn't feel compelled to name everything
"iPaq." This device is essentially a laptop with a strange case, no hard
drive, and 32MB of RAM. It has a VIA chipset and four USB ports. The
southbridge is a VT82C686 ("Apollo Super South"). It sports to UHCI USB
controllers sharing IRQ 11.
I have patched a long, thin logo into the kernel to replace the Tux
logo, but that is the only change I made.
When I insmod usb-uhci.o or uhci.o, it gets as far as ":
detected 2 ports" and then hangs, terminally. It does t his whether I
have usbcore compiled in or loaded as a module.
I have attached my .config file. Any help would be appreciated!
-M
#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y
#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
CONFIG_MK6=y
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_TSC=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_SMP is not set
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
#
# General setup
#
CONFIG_NET=y
# CONFIG_VISWS is not set
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y
#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=y
CONFIG_CARDBUS=y
CONFIG_I82365=y
# CONFIG_TCIC is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_PM=y
# CONFIG_ACPI is not set
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
CONFIG_APM_DISPLAY_BLANK=y
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
CONFIG_APM_REAL_MODE_POWER_OFF=y
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC1000 is not set
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOCPROBE is not set
#
# RAM/ROM Device Drivers
#
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_MTDRAM is not set
#
# Linearly Mapped Flash Device Drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_JEDEC is not set
# CONFIG_MTD_PHYSMAP is not set
#
# Drivers for chip mappings
#
# CONFIG_MTD_NORA is not set
# CONFIG_MTD_PNC2000 is not set
# CONFIG_MTD_RPXLITE is not set
#
# User modules and translation layers for MTD devices
#
# CONFIG_MTD_CHAR is not set
# CONFIG_MTD_BLOCK is not set
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play configuration
#
CONFIG_PNP=y
# CONFIG_ISAPNP is not set
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK=y
# CONFIG_RTNETLINK is not set
# CONFIG_NETLINK_DEV is not set
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
#
#
#
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is
Re: opening files in /proc, and modules
Sweet! Thanks!
I'm working on 2.2 for now, but the 2.4 API looks nicer... :)
-M
On 08 Mar 2001 11:43:24 -0500, Alexander Viro wrote:
>
>
> On 8 Mar 2001, Michael Rothwell wrote:
>
> > Figured it out -- I think. This appears to be the answer:
> >
> > In struct proc_dir_entry,set the fill_inode function pointer to a
> > callback to handle refcounts.
> >
> > struct proc_dir_entry
> > {
> > ...
> > void (*fill_inode)(struct inode *, int);
> > ...
> > };
> [snip]
> > ... right? :)
>
> Right for 2.2, wrong for 2.4. There you just set ->owner to THIS_MODULE
> and forget about the whole mess with callbacks.
> Cheers,
> Al
-
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: opening files in /proc, and modules
Figured it out -- I think. This appears to be the answer:
In struct proc_dir_entry,set the fill_inode function pointer to a
callback to handle refcounts.
struct proc_dir_entry
{
...
void (*fill_inode)(struct inode *, int);
...
};
void fill_inode_cb(struct inode *i, int v)
{
if (v==0)
{
MOD_DEC_USE_COUNT;
return;
};
if (v==1)
{
MOD_INC_USE_COUNT;
return;
};
};
... right? :)
On 08 Mar 2001 11:01:28 -0500, Michael Rothwell wrote:
> How can I detect that open() has been called on a file in procfs that a
> module provides? If I modprobe my module, open one or more if its proc
> entries, then rmmod the module while the proc files are still open, then
> the deletion of those entries is deferred. When I close the file(s), the
> kernel oopses. I need to be able to detect open() and close() in order
> to increment/decrement the reference count for my module, to prevent it
> from being rmmoded when in use. Any tips?
>
> Thanks!
>
> -
> 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/
-
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/
opening files in /proc, and modules
How can I detect that open() has been called on a file in procfs that a module provides? If I modprobe my module, open one or more if its proc entries, then rmmod the module while the proc files are still open, then the deletion of those entries is deferred. When I close the file(s), the kernel oopses. I need to be able to detect open() and close() in order to increment/decrement the reference count for my module, to prevent it from being rmmoded when in use. Any tips? Thanks! - 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/
physmem w/o proc
physmem= `head -10 /var/log/dmesg | grep Memory: | cut -d" " -f2 | cut -d "/" -f1 | cut -d"k" -f1` - 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: Q: How to get physical memory size from user space without procfs
pyhsmem = `free | grep Mem | tr -s "/ / /" | cut -f2 -d" "` On 03 Mar 2001 13:37:42 -0500, Denis Perchine wrote: > Hello, > > actually the question is in subj. > Problem is that there is a program which needs to know physical memory > size. This information is used to justify memory consumption as after some > swapping performance is drops dramatically, and it is better to finish. > > I know that this is not the best idea, but it is assumed that this program > is the only one running on the machine. > > I do not want to use proc as some people can just do not mount it. > > Any comments, suggestions? > > Thanks in advance. > > Denis Perchine. > > > > - > 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/ - 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: VT82C586B USB PCI card, Linux USB
On 03 Mar 2001 12:54:36 +0100, Vojtech Pavlik wrote: > No, they have a separate USB chip, but it has the same PCI ID as the > builtin silicon in the southbridge. Ah. I went and looked up that chip ID at via's website, and saw only southbridge chips, no USB-only chips at all. But, my real question was, is there a way to get it to work right under Linux? I have two machines; one is an Athlon with built-in (Via) USB support, and it seems to work ok. I also have a P-200 that's my print server, file server and (hopefully) scanner server. It is an old HX-chipset pre-USB socket-7 intel machine, but I've put a Via-chipset 2-port USB card into it. I keep getting timeouts on it. I've looked all over the net for clues as to what I can do to get it to work, and nothing has. Both uhci and usb-uhci have the same problems. Is there a generic cause for timeout problems when doing bulk transfers? - 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/
VT82C586B USB PCI card, Linux USB
I have a USB PCI card, which shows up as this in `lspci`: 00:09.0 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 04) ... it appears that they tossed the whole southbridge chip onto a pci board, and disabled everything but USB. Anyway, this device seems to be semi-functional under 2.2.18 USB. I have a cheapie IBM usb camera that works, but a USB scanner that does not -- always gives the following errors: usb_control/bulk_msg: timeout scanner.c: write_scanner: NAK received. The firmware upload seems to work ok, but nothing else does. The sane tools actually segfault, and once the kernel oopsed (didn't manage to get the output :( ). I noticed a config setting for that chipset, but it was under block devices, so I left it turned off. Judging form reading the LKML, VIA chipsets are problematic. Has anyone has any positive experiences getting this device to do the thing it's supposed to do under Linux? Any tips? -M - 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: CPRM is dead; Thanks Andre!
> IBM withdrew the proposal. ... from public view - 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: LILO and serial speeds over 9600
> Then HPA may ask: but why do you want to run the serial console at
> 115200?? The answer is simple: because we ...
... don't want to drag out debugging the kernel on a 38400 connection.
Because printks are our only debugging option ("thanks", Linus), and a slow
serial port block and can change the timing of when code runs, I need the
serial port to run as fast as possible. It would be keen to be able to use
an ethernet debugging console rather than (or in addition to) serial,
because it would be even faster, and if I'm debugging (for instance) a
serial driver, I won't have to use the system I'm debugging to debug the
system I'm debugging.
Of course, a supported kernel debugger would make a nice addition to faster
console output, but I won't hold my breath waiting for Linux to acquire what
pretty much every other operating system already has.
-M
-
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://vger.kernel.org/lkml/
Re: "kaweth" usb ethernet driver in 2.4?
Thanks. Has Brad Hards made his version available somewhere? -M - Original Message - From: "Eric Sandeen" <[EMAIL PROTECTED]> To: "Michael Rothwell" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, February 04, 2001 9:30 AM Subject: Re: "kaweth" usb ethernet driver in 2.4? > Michael Rothwell wrote: > > > > It also doesn't seem to work in 2.2. :) The original development of > > > this driver was going on at http://drivers.rd.ilan.net/kaweth/ but there > > > have been no updates for quite some time. > > > > Well, it doesn't work you _you_ on 2.2, obviously. But it works for us > > and other people. Can you provide any information to diagnose the > > problem you're having? > > I'm sorry, I should have provided that info. I searched the 'net, and > saw many people with problems on several mailing lists, and saw no > solutions, or reports of success, so I assumed that it was a widespread, > possibly even known, problem with the driver. > > I'll preface this by saying that Brad Hards sent me an updated version > that works much better, at least as long as the module is loaded before > the device is plugged in. > > But here's what I get with a 2.2 kernel and the stock driver: > > Kawasaki USB->Ethernet Driver loading... > usb.c: registered new driver kaweth > usb.c: USB new device connect, assigned device number 2 > Kawasaki Device Probe (Device number:2): 0x0846:0x1001 > Device at c2192600 > Descriptor length: 12 type: 1 > NetGear EA-101 connected... > Reading kaweth configuration > Request type: c0 Request: 0 Value: 0 Index: 0 Length: 12 > usb-uhci.c: interrupt, status 2, frame# 1929 > kaweth control message failed (urb addr: c2c05ca0) > usb_control/bulk_msg: timeout > usb-uhci.c: interrupt, status 2, frame# 851 > Actual length: 0, length 18 > Resetting... > usb-uhci.c: interrupt, status 2, frame# 854 > Downloading firmware at c48abb6c to kaweth device at c31be000... > Firmware length: 3838 > Request type: 40 Request: ff Value: 0 Index: 0 Length: efe > usb-uhci.c: interrupt, status 2, frame# 871 > kaweth control message failed (urb addr: c213ab60) > usb-uhci.c: interrupt, status 2, frame# 877 > usb-uhci.c: interrupt, status 2, frame# 882 > Actual length: 0, length 3838 > Error downloading firmware (-110), no net device created > - 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: "kaweth" usb ethernet driver in 2.4?
On 03 Feb 2001 14:22:02 -0600, Eric Sandeen wrote: > The driver is included with the USB stuff for 2.2, but not in 2.4. That's because we stopped fooling with 2.4 around the middle of the pre-test-ac series of releases. We'll probably pick it back up around 2.4.7 or so. > It also doesn't seem to work in 2.2. :) The original development of > this driver was going on at http://drivers.rd.ilan.net/kaweth/ but there > have been no updates for quite some time. Well, it doesn't work you _you_ on 2.2, obviously. But it works for us and other people. Can you provide any information to diagnose the problem you're having? And, truthfully, you'd be better off tossing it in the trash and buying a better product. It's VERY lossy with packets and slow. And it's not just our driver; it's the device itself. It sucks on Windows as well. :) However, if you post some info about your experience with it, perhaps we can get it working for you. But not on 2.4 for awhile. -M - 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: named streams, extended attributes, and posix
Mo McKinlay wrote: > I would too, but POSIX won't let us unless we start enforcing side-effect > rules for all filesystems. Hence why I came up with openstream() :) So, openstream() is probably the most painless way to get named streams support into Linux in the immediate future. Openstream() will have to fail on filesystems that do not support streams, ideally without changing those filesystems. And as long as we're adding a system call to deal with streams, we should consider adding the functions for extended attributes at the same time. >From http://www.flyingbuttmonkeys.com/streams-on-posix.txt ... Minimum VFS Support vop_eattr_get - read an EA vop_eattr_set - set an EA vop_eattr_remove - remove an EA vop_eattr_list - list the EAs like vop_readdir would a directory. Optional Support vop_eattr_create - Create an EA or error if it exists. vop_eattr_multi - perform a sequence of EA vops atomically. vop_eattr_rename - change the name of an EA vop_eattr_serialize - export all the EAs as a stream of entries. Thoughts? You mught want to refer back to the paper to get the whole EAs proposal... -M - 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/
unmapping inode?
>From within a filesystem driver, how would I completely remove a page cache mapping for an inode in 2.2.18? -M - 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: named streams, extended attributes, and posix
What you say is true; but Win32 -- which pretty much all Windows apps use -- disallows the following: \/:*?"<>| ... from that, they chose ":" as the stream delimiter, since the only other place it is used is with the drive letters. For the user, and most (non-native, i.e., Win32) apps, there are limitations on what a filename can contain. -M - Original Message - From: "Albert D. Cahalan" <[EMAIL PROTECTED]> To: "Michael Rothwell" <[EMAIL PROTECTED]> Cc: "Mo McKinlay" <[EMAIL PROTECTED]>; "Peter Samuelson" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, January 20, 2001 11:27 PM Subject: Re: named streams, extended attributes, and posix > Michael Rothwell writes: > > ... > >> Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: > > >>> The filesystem, when registering that it supports the "named streams" > >>> namespace, could specify its preferred delimiter to the VFS as well. > >>> Ext4 could use /directory/file/stream, and NTFS could use > >>> /directory/file:stream. > ... > > Oh, undoubtedly. But NTFS already disallows several characters > > in valid filenames. > > NTFS allows all 16-bit characters in filenames, including 0x. > Nothing is disallowed. The NT kernel's native API uses counted > Unicode strings. The strings can be huge too, like 128 kB. > > So there isn't _any_ safe delimiter. > > Win32 will choke on 0x and a few other things, allowing a > clever person to create apparently inaccessible files. > - > 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/ > - 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/
2.2.18 and mkraid
What version of the raidtools to I need for 2.2.18 software raid? Documentation/md.txt has a non-functional URL in it. Thanks. -M - 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: named streams, extended attributes, and posix
Mo McKinlay wrote: > Nono, that's not what I mean - each of the filesystems fails if it > doesn't support what you're trying to do, that's given - but having a > different delimeter registered by the filesystem (and hence the > possibility of every single filesystem using a different delimeter) brings > about a completely different kind of inconsistency. True. Which is why I'd prefer a standard delimiter. ":" seems to be the top candidate. - 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: named streams, extended attributes, and posix
Mo McKinlay wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: > > > The filesystem, when registering that it supports the "named streams" > > namespace, could specify its preferred delimiter to the VFS as well. > > Ext4 could use /directory/file/stream, and NTFS could use > > /directory/file:stream. > > Erk - nice from a programming point of view, horrible from a consistency > one. The nice thing about VFS is that it provides a consistent abstract > interface - I'd place a small amount of money on the fact that Al Viro > would probably flame you to high heaven for that last suggestion if he was > paying much attention to this thread :-) Oh, undoubtedly. But NTFS already disallows several characters in valid filenames. This also violates the "consistent abstract interface." But it's reality. -M - 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: named streams, extended attributes, and posix
Mo McKinlay wrote: > (Take symbolic linking, for example - if you ln -s on VFAT, you get > 'operation not permitted' - named stream/EA operations on a filesystem > that doesn't support them should return the same, IMHO). And they would, if the chosen namespace was not supported. > Also, I don't like the idea of bypassing POSIX in this manner (using ':' > as a delimeter), even if the underlying filesystem *may* not support it. > > What's to say that ext4 (or whatever) won't support named streams, but > still allow ':'? Your solution as it stands would break in that situation > (assuming I've not missed something :) The filesystem, when registering that it supports the "named streams" namespace, could specify its preferred delimiter to the VFS as well. Ext4 could use /directory/file/stream, and NTFS could use /directory/file:stream. -M - 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: named streams, extended attributes, and posix
Mo McKinlay wrote: > openstream(file, stream, flags) > > Where 'file' should be an fd (although i'm sure the VFS gods will think of > plenty of reasons why this is a bad idea, at which point I'll > conventiently change my mind ;). Stream is simply the name of the stream, > flags are as with open() (O_RDONLY, et al). openstream() then returns an > fd which can be read/written/sendfiled/closed as the programmer wishes. I'm not opposed to that, and think it is even a useful idea. Sort of like fdopen(). > Apart from the additional of a new open()-type call, your paper seems to > be fairly solid. Thanks. I think having the option of the namespace augmentation would be useful, in terms of supporting existing filesystems. On NTFS, ":" is not a legal filename character anyway. The namespace augmentation suggested in the paper would allow filesystems like NTFS to work as they should, and all other filesystems to ignore it. -M - 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: named streams, extended attributes, and posix
Mo McKinlay wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: > > > Unfortunately, unix allows everything but "/" in filenames. This was > > probably a mistake, as it makes it nearly impossible to augment the > > namespace, but it is the reality. > > > Did you read the "new namespace" section of the paper? > > I've not, so pardon me if I make a bad assumption (and slap me for it, > too), but doesn't introducing a new namespace segregate the streams from > the files/directories, thus introducing an artifical separation which > isn't really there? (Pretty much why I'm more in favour of a specific API > for reading streams, extended attributes and whatnot, over any of the > other solutions thus suggested). Well, EAs are accessed via a special API. The paper also covers that. Streams, however, are by nature accessed as files; this is what makes them not EAs. EAs are set and retrieved atomically. Streams can be used with open(), seek(), read(), write(), etc. This is actually more "unixy" than EAs, as the usual set of Unix functions and tools can work with streams unmodified; i.e., without knowledge of a special API. Of course, cp() is the exception. It would have to be able to enumerate and copy all the streams. If you have time, please read over the paper so we don't get into the same rut we got into last time. :) http://www.flyingbuttmonkeys.com/streams-on-posix.txt http://www.flyingbuttmonkeys.com/streams-on-posix.pdf -M - 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:
Robert Kaiser wrote: > > On Thu Jan 18 16:30:30 2001 [EMAIL PROTECTED] wrote > > Has anyone had any luck getting a 2.4 kernel to run on Cobalt x86 > > hardware? It doesn't even seem to start (I get nothing on the screen from > >t he kernel, it just sits there and does nothing). :( > > What processor does it use ? (386 or 486 perchance?) AMD K6. New ones will use Athlon. - 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: named streams, extended attributes, and posix
Unfortunately, unix allows everything but "/" in filenames. This was
probably a mistake, as it makes it nearly impossible to augment the
namespace, but it is the reality.
Did you read the "new namespace" section of the paper?
It also talked a bit about supporting Extended Attributes, which are access
via an API and not with a filename separator. We could, perhaps, begin by
supporting EAs. That would take care of HFS, HPFS, XFS, and BeFS, and half
of NTFS. Then we could go on to tackle the Named Streams problem.
-M
- Original Message -
From: "Mo McKinlay" <[EMAIL PROTECTED]>
To: "Peter Samuelson" <[EMAIL PROTECTED]>
Cc: "Mo McKinlay" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, January 18, 2001 1:30 PM
Subject: Re: named streams, extended attributes, and posix
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Yesterday, Peter Samuelson ([EMAIL PROTECTED]) wrote:
>
> > Yeah, I agree, 'file/stream' is lousy syntax as well. If it weren't
> > for the possibility of having streams on directories, it would almost
> > be acceptible. I still don't know which (':' or '/') is the worse
> > hack.
>
> Me neither :/
>
> > As I've said elsewhere in this thread, I can't think of *any* clean
way
> > to shoehorn forks into nice, transparent posix calls. It really wants
> > a new API.
>
> Likewise. This was my standpoint the last time around - a clear concise
> portable API for accessing streams (even if it *started out*
> Linux-specific) - without imposing silly semantics on existing
> applications which currently ignore streams anyway.
>
> Mo.
>
> - --
> Mo McKinlay
> [EMAIL PROTECTED]
> -
-
> GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22
>
>
>
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iEYEARECAAYFAjpnYGQACgkQRcGgB3aidfmWBQCfXgNq/vqltt76mApoDiNI9HnH
> ws8AoJZ2vvlH1iCAeUu7yktWWN0Bncc3
> =gEmD
> -END PGP SIGNATURE-
>
> -
> 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/
>
-
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: named streams, extended attributes, and posix
> What if you copy both 'filename' and 'filename:ext' onto the same fs? > Do they get combined into one file? ON Ext2, you get two files. On NTFS, you get one file, and a stream on that file. > Any semantics by which 'filename:stream' and 'filename' refer to the > same file would be b0rken. If instead you use 'filename/stream' That does not allow streams on directories, otherwise I agree. -M - 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: named streams, extended attributes, and posix
"James H. Cloos Jr." wrote: > > Michael> Please read and comment! :) > > There should be some discussion on what to do about filenames which > contain colons in such a setup. Moving a file w/ a colon from a fs > which does not support named streams to one which does should DTRT; > exactly what TRT is should be discussed. It seems that if you move a file with a colon -- "file:colon" -- in the name from Ext2 to "StreamFS," you would end up with a file named "file" with a stream named "colon". When copying back, you would get "file:colon" back. - 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: O_NONBLOCK, read(), select(), NFS, Ext2, etc.
Alan Cox wrote: > > > using the O_NONBLOCK flag, then read() and write() will always return > > immediately and not block the calling process. This does not appear to > > be true; but perhaps I am doing something wrong. If I open() a file (on > > 2.2.18) from a floppy or NFS mount (to test in a slow environment) with > > O_NONBLOCK|O_RDONLY, read() will still block. If I try to select() on > > the file descriptor, select() always returns 0. > > The definition of immediate is not 'instant'. Otherwise no I/O system would > ever return anything but -EWOULDBLOCK. Its that it won't wait when there is > no data pending. On a floppy there is always data pending How about using fcntl(), O_ASYNC and SIGIO? Or maybe a broader question: what's the preferred/working way to do async file i/o on Linux? -M - 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/
O_NONBLOCK, read(), select(), NFS, Ext2, etc.
The man pages for open, read and write say that if a file is opened using the O_NONBLOCK flag, then read() and write() will always return immediately and not block the calling process. This does not appear to be true; but perhaps I am doing something wrong. If I open() a file (on 2.2.18) from a floppy or NFS mount (to test in a slow environment) with O_NONBLOCK|O_RDONLY, read() will still block. If I try to select() on the file descriptor, select() always returns 0. Is there a way to make open(), read() and write() live up to their manpages? -M - 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: named streams, extended attributes, and posix
CORRECTION: > existing, widely-deployed filesystems (e.g., NFS, XFS, BeFS, HFS, etc.), NTFS---^ - 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/
named streams, extended attributes, and posix
Now that 2.4 is out, it will probably be a few .x releases until 2.5 begins. A discussion on Named Streams and Extended Attributes was put off until 2.5 earlier in the 2.4 development cycle. For compatibility with existing, widely-deployed filesystems (e.g., NFS, XFS, BeFS, HFS, etc.), Linux needs a standard way to expose and interact with these filesystem features. A draft of a paper proposing a methd for accomplishing this on Posix systems is available at: http://www.flyingbuttmonkeys.com/streams-on-posix.txt http://www.flyingbuttmonkeys.com/streams-on-posix.pdf Please read and comment! :) -M - 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: Journaling: Surviving or allowing unclean shutdown?
> On Wed, 3 Jan 2001, Dr. David Gilbert wrote: > > > I got wondering as to whether the various journaling file > > system activities were designed to survive the occasional > > unclean shutdown or were designed to allow the user to just pull > > the plug as a regular means of shutting down. > > > Thoughts? Journaling filesystems only guarantee consistancy of filesystem metadata. Data that has not been flushed from buffers will be lost, and applications not given a chance to shut themselves down may do bad things if you just unplug the box. Journaling mostly means not having to run FSCK. -M - 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: high load & poor interactivity on fast thread creation
Ruth Ivimey-Cook wrote: > No. Java on NT uses proper NT threads. However, a thread on NT is a rather > different beast to a cloned thread on Linux. I don't know whether the > differences are important. On Linux, threads are processes. On NT, processes are distinct from threads, and usually have at least one thread within them. On Linux, the process and the initial (sole) thread are the same thing. On NT, they are distinct. CreateProcess() creates a process and its initial thread (because that is what you would expect to happen). On Linux, clone() creates a new process; sometimes that process can be construed as a thread, because of shared memory, file descriptors, or whatever. On NT, because a process contains threads and is not itself a thread, you can use CreateProcess() to create a process whose only thread is suspended. I don't know if that kind of thing is possible with clone(). You might have to clone() then suspend. You use CreateThread() to create more threads inside an existing process. CreateRemoteThread() creates new threads inside a different process. A process is more of a virtual memory environment and container for threads than a context of execution itself. With clone() on Linux you can mimic a lot of the behavior of NT processes and threads, but not all of it. One notable difference between Linux and NT threads and processes is that it is more expensive to create new processes on NT than on Linux, and on NT thread creation is cheaper than process creation. Typically Windows programs use multiple threads rather than multiple processes, whereas on Unix the reverse is true. http://www.byte.com/art/9511/sec11/art3.htm http://msdn.microsoft.com/library/winresource/dnwinnt/S7FC7.HTM http://msdn.microsoft.com/library/psdk/winbase/prothred_9dpv.htm http://msdn.microsoft.com/library/psdk/winbase/prothred_4084.htm - 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: iptables: "stateful inspection?"
Felix von Leitner wrote: > > > IPChains is essentially useless as a firewall due to its lack of > > stateful packet filering. > > Bullshit. > Go back to the bowels or Redmond where you belong, luser. Thanks. I appreciate that. -M - 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: iptables: "stateful inspection?"
Alan Cox wrote: > There have been at least five holes found in pile that _could_ have been > [speech] > safe is the day you end up hurt. Your specific example of an executable (windows) attachment, not buffer overflows, etc. what what I was replying to. In general, you are correct. Now, how about including that procfs cleanup patch that I sent, and maybe the 64-bit printk patch? :) -M - 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: iptables: "stateful inspection?"
Alan Cox wrote: > It does SYN checking. If you are running 'serious' security you wouldnt be > allowing outgoing connections anyway. One windows christmascard.exe virus that > connects back to an irc server to take input and you are hosed. Thankfully, pine and mutt are, to date, immune to that kind of thing. :) -M - 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: iptables: "stateful inspection?"
"Michael H. Warfield" wrote: > You can use spf to add some stateful inspection for PORT mode > ftp. Personally, I like the masquerading option better, though. Can you give an example of using MASQ selectively? I have real addresses on both sides of the firewall, but want things like FTP to work correctly. I think the IPChains HOWTOs are just a little terse. :) Thanks! - 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: iptables: "stateful inspection?"
"Michael H. Warfield" wrote: > I think that's more than a little overstatement on your > part. It depends entirely on the application you intend to put > it to. Fine. How do I make FTP work through it? How can I allow all outgoing TCP connections without opening the network to inbound connections on the ports of desired services? > Yes it does. It's clearly stated in all the documentation > on netfilter and in it's design. Read the fine manual (or web site) > and you would have uncovered this (or been run over by it) for yourself. > > http://netfilter.filewatcher.org/ Thanks. -M - 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/
iptables: "stateful inspection?"
IPChains is essentially useless as a firewall due to its lack of stateful packet filering. Will the IPTables code in 2.4 maintain connection state? -M - 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] Re: Linux 2.2.19pre1 : procfs api
Heh. Mangleage. :) Willy Tarreau wrote: > > Hello Michael, I wonder about this patch which only fixes an Id/author but no > code. It may be perfectly normal, but could also come from a mangled file in > one of your trees. Just for info anyway... > > Cheers, > Willy > > > diff -r -u -x CVS -x *.o linux-2.2.18pre25-VIRGIN/fs/proc/openpromfs.c > zinux/fs/proc/openpromfs.c > > --- linux-2.2.18pre25-VIRGIN/fs/proc/openpromfs.c Fri Dec 8 14:57:07 2000 > > +++ zinux/fs/proc/openpromfs.cFri Dec 8 15:08:59 2000 > > @@ -1,4 +1,4 @@ > > -/* $Id: openpromfs.c,v 1.33 1999/04/28 11:57:33 davem Exp $ > > +/* $Id: openpromfs.c,v 1.1.1.1 2000/12/08 20:08:59 zapman Exp $ > > * openpromfs.c: /proc/openprom handling routines > > * > > * Copyright (C) 1996-1998 Jakub Jelinek ([EMAIL PROTECTED]) - 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] Re: Linux 2.2.19pre1 64-bit printk
Alan Cox wrote:
> Ok this is the first block of changes before we merge the VM stuff. This is
> mostly the bits left over from the 2.2.18 port that were deferred as too
> risky near the end of a prerelease set and some bug swats
And here is the 64-bit printk patch -- a backport of the 2.4.0 code.
diff -B --unidirectional-new-file --exclude-from=DiffExcludeList --recursive --unified
linux-2.2.16/include/asm-alpha/div64.h linux/include/asm-alpha/div64.h
--- linux-2.2.16/include/asm-alpha/div64.h Wed Dec 31 19:00:00 1969
+++ linux/include/asm-alpha/div64.h Fri Aug 11 20:04:18 2000
@@ -0,0 +1,14 @@
+#ifndef __ALPHA_DIV64
+#define __ALPHA_DIV64
+
+/*
+ * Hey, we're already 64-bit, no
+ * need to play games..
+ */
+#define do_div(n,base) ({ \
+ int __res; \
+ __res = ((unsigned long) (n)) % (unsigned) (base); \
+ (n) = ((unsigned long) (n)) / (unsigned) (base); \
+ __res; })
+
+#endif
diff -B --unidirectional-new-file --exclude-from=DiffExcludeList --recursive --unified
linux-2.2.16/include/asm-arm/div64.h linux/include/asm-arm/div64.h
--- linux-2.2.16/include/asm-arm/div64.hWed Dec 31 19:00:00 1969
+++ linux/include/asm-arm/div64.h Fri Aug 11 20:05:41 2000
@@ -0,0 +1,14 @@
+#ifndef __ASM_ARM_DIV64
+#define __ASM_ARM_DIV64
+
+/* We're not 64-bit, but... */
+#define do_div(n,base) \
+({ \
+ int __res; \
+ __res = ((unsigned long)n) % (unsigned int)base;\
+ n = ((unsigned long)n) / (unsigned int)base;\
+ __res; \
+})
+
+#endif
+
diff -B --unidirectional-new-file --exclude-from=DiffExcludeList --recursive --unified
linux-2.2.16/include/asm-i386/div64.h linux/include/asm-i386/div64.h
--- linux-2.2.16/include/asm-i386/div64.h Wed Dec 31 19:00:00 1969
+++ linux/include/asm-i386/div64.h Fri Aug 11 20:06:05 2000
@@ -0,0 +1,17 @@
+#ifndef __I386_DIV64
+#define __I386_DIV64
+
+#define do_div(n,base) ({ \
+ unsigned long __upper, __low, __high, __mod; \
+ asm("":"=a" (__low), "=d" (__high):"A" (n)); \
+ __upper = __high; \
+ if (__high) { \
+ __upper = __high % (base); \
+ __high = __high / (base); \
+ } \
+ asm("divl %2":"=a" (__low), "=d" (__mod):"rm" (base), "0" (__low), "1"
+(__upper)); \
+ asm("":"=A" (n):"a" (__low),"d" (__high)); \
+ __mod; \
+})
+
+#endif
diff -B --unidirectional-new-file --exclude-from=DiffExcludeList --recursive --unified
linux-2.2.16/include/asm-m68k/div64.h linux/include/asm-m68k/div64.h
--- linux-2.2.16/include/asm-m68k/div64.h Wed Dec 31 19:00:00 1969
+++ linux/include/asm-m68k/div64.h Fri Aug 11 20:06:57 2000
@@ -0,0 +1,35 @@
+#ifndef _M68K_DIV64_H
+#define _M68K_DIV64_H
+
+/* n = n / base; return rem; */
+
+#if 1
+#define do_div(n, base) ({ \
+ union { \
+ unsigned long n32[2]; \
+ unsigned long long n64; \
+ } __n; \
+ unsigned long __rem, __upper; \
+ \
+ __n.n64 = (n); \
+ if ((__upper = __n.n32[0])) { \
+ asm ("divul.l %2,%1:%0" \
+ : "=d" (__n.n32[0]), "=d" (__upper) \
+ : "d" (base), "0" (__n.n32[0]));\
+ } \
+ asm ("divu.l %2,%1:%0" \
+ : "=d" (__n.n32[1]), "=d" (__rem) \
+ : "d" (base), "1" (__upper), "0" (__n.n32[1])); \
+ (n) = __n.n64; \
+ __rem; \
+})
+#else
+#define do_div(n,base) ({ \
+ int __res; \
+ __res = ((unsigned long) n) % (unsigned) base; \
+ n = ((unsigned long) n) / (unsigned) base; \
+ __res; \
+})
+#endif
+
+#endif /* _M68K_DIV64_H */
diff -B --unidirectional-new-file --exclude-from=DiffExcludeList --recursive --unified
linux-2.2.16/include/asm-mips/div64.h linux/include/asm-mips/div64.h
--- linux-2.2.16/include/asm-mips/div64.h Wed Dec 31 19:00:00 1969
+++ linux/include/asm-mips/div64.h Fri Aug 11 20:41:49 2000
@@ -0,0 +1,20 @@
+/* $Id: div64.h,v 1.1.2.1 2000/08/12 00:41:49 zapman Exp $
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * Li
[PATCH] Re: Linux 2.2.19pre1 : procfs api
Alan Cox wrote:
> Ok this is the first block of changes before we merge the VM stuff. This is
> mostly the bits left over from the 2.2.18 port that were deferred as too
> risky near the end of a prerelease set and some bug swats
Here's the procfs patch again... :) Because the 2.2.18 procfs api is
different than both 2.2.17 and 2.4.0, this patch makes it work like
2.4.0. It seems like the 2.2.18 changes were a half-way implementation
of the 2.4.0 api.
--- linux-2.2.18pre25-VIRGIN/include/linux/proc_fs.hFri Dec 8 14:57:08 2000
+++ zinux/include/linux/proc_fs.h Fri Dec 8 23:21:26 2000
@@ -262,6 +262,12 @@
#define PROC_SUPER_MAGIC 0x9fa0
+typedefint (read_proc_t)(char *page, char **start, off_t off,
+ int count, int *eof, void *data);
+typedefint (write_proc_t)(struct file *file, const char *buffer,
+ unsigned long count, void *data);
+typedef int (get_info_t)(char *, char **, off_t, int, int);
+
/*
* This is not completely implemented yet. The idea is to
* create an in-memory tree (like the actual /proc filesystem
@@ -287,24 +293,17 @@
gid_t gid;
unsigned long size;
struct inode_operations * ops;
- int (*get_info)(char *, char **, off_t, int, int);
+ get_info_t *get_info;
void (*fill_inode)(struct inode *, int);
struct proc_dir_entry *next, *parent, *subdir;
void *data;
- int (*read_proc)(char *page, char **start, off_t off,
-int count, int *eof, void *data);
- int (*write_proc)(struct file *file, const char *buffer,
- unsigned long count, void *data);
+ read_proc_t *read_proc;
+ write_proc_t *write_proc;
int (*readlink_proc)(struct proc_dir_entry *de, char *page);
unsigned int count; /* use count */
int deleted;/* delete flag */
};
-typedefint (read_proc_t)(char *page, char **start, off_t off,
- int count, int *eof, void *data);
-typedefint (write_proc_t)(struct file *file, const char *buffer,
- unsigned long count, void *data);
-
extern int (* dispatch_scsi_info_ptr) (int ino, char *buffer, char **start,
off_t offset, int length, int inout);
@@ -433,15 +432,33 @@
/*
* generic.c
*/
+extern struct proc_dir_entry *proc_symlink(const char *,
+ struct proc_dir_entry *, const char *);
+extern struct proc_dir_entry *proc_mkdir(const char *,struct proc_dir_entry *);
+
struct proc_dir_entry *create_proc_entry(const char *name, mode_t mode,
struct proc_dir_entry *parent);
void remove_proc_entry(const char *name, struct proc_dir_entry *parent);
-#define create_proc_info_entry(n, m, b, g) \
- { \
- struct proc_dir_entry *r = create_proc_entry(n, m, b); \
- if (r) r->get_info = g; \
+extern inline struct proc_dir_entry *create_proc_read_entry(const char *name,
+ mode_t mode, struct proc_dir_entry *base,
+ read_proc_t *read_proc, void * data)
+{
+ struct proc_dir_entry *res=create_proc_entry(name,mode,base);
+ if (res) {
+ res->read_proc=read_proc;
+ res->data=data;
}
+ return res;
+}
+
+extern inline struct proc_dir_entry *create_proc_info_entry(const char *name,
+ mode_t mode, struct proc_dir_entry *base, get_info_t *get_info)
+{
+ struct proc_dir_entry *res=create_proc_entry(name,mode,base);
+ if (res) res->get_info=get_info;
+ return res;
+}
/*
* proc_tty.c
@@ -470,12 +487,18 @@
return NULL;
}
-#define create_proc_info_entry(n, m, b, g) \
- { \
- struct proc_dir_entry *r = create_proc_entry(n, m, b); \
- if (r) r->get_info = g; \
- }
-
+extern inline struct proc_dir_entry *create_proc_read_entry(const char *name,
+ mode_t mode, struct proc_dir_entry *base,
+
+ read_proc_t read_proc,
+ void * data) { return NULL; }
+extern inline struct proc_dir_entry *create_proc_info_entry(const char *name,
+ mode_t mode, struct proc_dir_entry *base, get_info_t *get_info)
+ { return NULL; }
+
+extern inline struct proc_dir_entry *proc_symlink(const char *name,
+ struct proc_dir_entry *parent,char *dest) {return NULL;}
+extern inline struct proc_dir_entry *proc_mkdir(const char *name,
+ struct proc_dir_entry *parent) {return NULL;}
extern inline void remove_proc_entry(const char *name, struct proc_dir_entry *parent)
{};
@@ -485,7 +508,5 @@
extern struct proc_dir_entry proc_root;
#endif /* CONFIG_PROC_FS */
-
-#define proc_mkdir(buf, usbdir)create_proc_entry(buf, S_IFDIR, usbdir)
#endif /* _LINUX_PROC_FS_H */
diff -r -u -x CVS -x *.o linux-2.2.18pre25-VIRGIN/fs
Re: ANNOUNCE: Linux Kernel ORB: kORBit
> Also, 9P is a general communications framework only in the context of > Plan9 itself. In reality it only applys directly/well to filesystem > related issues... the reason it works well in Plan9 is that _everything_ > is a file (part of the beauty of plan9). So... in a 9P-enabled system, you write a regular server program that uses read(), write(), etc. to use the local (or another, remote) 9P system and exports some interface over the network protocol and encapsulation format of your choice. In your case, CORBA over IIOP or something. :) -M - 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: Linux Kernel ORB: kORBit
Alexander Viro wrote: > p9fs exists. I didn't see these patches since August, but probably I can poke > Roman into porting it to the current tree. 9P is quite simple and unlike > CORBA it had been designed for taking kernel stuff to userland. Besides, > authors definitely understand UNIX... I would side with Viro here. Just as we would all cringe if MSFT added COM/ActiveX support to the NT kernel, us Unix folks cringe at the thought of adding CORBA to the kernel. However, that doesn't mean that we dislike the idea of exporting kernel services and interfaces for use in userland. And Plan9 seems to have some rather elegant and efficient methods for doing that. In Plan9, everything really is a file! It's as if they got a chance to do Unix again, and they did it consistently this time. - 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: linux 2.2.18 inconsistencies/problems (minor)
Alan Cox wrote: > Real bug - thanks. I'll squash that in 19pre1 When will you be starting 19pre1? - 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: Linux Kernel ORB: kORBit
josef höök wrote: > > What about implementing 9P instead That would rock. Plan9 is unix done the right way -- i.e., the fully consistent way. I'd love to see 9p in Linux. We're heading that direction anyway, with procfs, devfs, etc. - 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: Linux Kernel ORB: kORBit
Ben Ford wrote: > Why would you *ever* want to write a device driver in perl??? Well, Perl, I don't know. But the USB 'driver' for my Canon PowerShot S20 runs in userspace. Seems a safer place to do things. -M - 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: Linux 2.2.18 almost...
Alan Cox wrote: > > The patch I intend to be 2.2.18 is out as 2.2.18pre26 in the usual place. > I'll move it over tomorrow if nobody reports any horrors, missing files etc Fresh 2.2.17, "patch -p1 < /pre-patch-2.2.18-26" can't find file to patch at input line 38909 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |diff -u --new-file --recursive --exclude-from /usr/src/exclude v2.2.17/arch/i386/vmlinux.lds linux/arch/i386/vmlinux.lds |--- v2.2.17/arch/i386/vmlinux.lds Wed May 3 21:22:13 2000 |+++ linux/arch/i386/vmlinux.ldsSat Dec 9 21:23:21 2000 - 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] 2.4.0 proc_fs for 2.2.18: UPDATED
Michael Rothwell wrote:
>
> Alan Cox wrote:
> >
> > > Why is 2.2.18 proc_fs.c different than both 2.2.17 and 2.4.0? Cox, would
> > > you accept a patch that makes 2.2.18 define create_proc_info_entry and
> > > related functions the same way that 2.4.0 does?
> >
> > Send me a diff and I'll be happy to
>
> Here it is, both inlined and as an attachment. It's been tested;
> compiles, boots, works. Let me know what you think.
>
> -M
>
Okay, A function got left out. Here's the newer version. :)
--- linux-2.2.18pre25-VIRGIN/include/linux/proc_fs.hFri Dec 8 14:57:08
2000
+++ zinux/include/linux/proc_fs.h Fri Dec 8 23:21:26 2000
@@ -262,6 +262,12 @@
#define PROC_SUPER_MAGIC 0x9fa0
+typedefint (read_proc_t)(char *page, char **start, off_t off,
+ int count, int *eof, void *data);
+typedefint (write_proc_t)(struct file *file, const char *buffer,
+ unsigned long count, void *data);
+typedef int (get_info_t)(char *, char **, off_t, int, int);
+
/*
* This is not completely implemented yet. The idea is to
* create an in-memory tree (like the actual /proc filesystem
@@ -287,24 +293,17 @@
gid_t gid;
unsigned long size;
struct inode_operations * ops;
- int (*get_info)(char *, char **, off_t, int, int);
+ get_info_t *get_info;
void (*fill_inode)(struct inode *, int);
struct proc_dir_entry *next, *parent, *subdir;
void *data;
- int (*read_proc)(char *page, char **start, off_t off,
-int count, int *eof, void *data);
- int (*write_proc)(struct file *file, const char *buffer,
- unsigned long count, void *data);
+ read_proc_t *read_proc;
+ write_proc_t *write_proc;
int (*readlink_proc)(struct proc_dir_entry *de, char *page);
unsigned int count; /* use count */
int deleted;/* delete flag */
};
-typedefint (read_proc_t)(char *page, char **start, off_t off,
- int count, int *eof, void *data);
-typedefint (write_proc_t)(struct file *file, const char *buffer,
- unsigned long count, void *data);
-
extern int (* dispatch_scsi_info_ptr) (int ino, char *buffer, char
**start,
off_t offset, int length, int inout);
@@ -433,15 +432,33 @@
/*
* generic.c
*/
+extern struct proc_dir_entry *proc_symlink(const char *,
+ struct proc_dir_entry *, const char *);
+extern struct proc_dir_entry *proc_mkdir(const char *,struct
proc_dir_entry *);
+
struct proc_dir_entry *create_proc_entry(const char *name, mode_t mode,
struct proc_dir_entry *parent);
void remove_proc_entry(const char *name, struct proc_dir_entry
*parent);
-#define create_proc_info_entry(n, m, b, g) \
- { \
- struct proc_dir_entry *r = create_proc_entry(n, m, b); \
- if (r) r->get_info = g; \
+extern inline struct proc_dir_entry *create_proc_read_entry(const char
*name,
+ mode_t mode, struct proc_dir_entry *base,
+ read_proc_t *read_proc, void * data)
+{
+ struct proc_dir_entry *res=create_proc_entry(name,mode,base);
+ if (res) {
+ res->read_proc=read_proc;
+ res->data=data;
}
+ return res;
+}
+
+extern inline struct proc_dir_entry *create_proc_info_entry(const char
*name,
+ mode_t mode, struct proc_dir_entry *base, get_info_t *get_info)
+{
+ struct proc_dir_entry *res=create_proc_entry(name,mode,base);
+ if (res) res->get_info=get_info;
+ return res;
+}
/*
* proc_tty.c
@@ -470,12 +487,18 @@
return NULL;
}
-#define create_proc_info_entry(n, m, b, g) \
- { \
- struct proc_dir_entry *r = create_proc_entry(n, m, b); \
- if (r) r->get_info = g; \
- }
-
+extern inline struct proc_dir_entry *create_proc_read_entry(const char
*name,
+ mode_t mode, struct proc_dir_entry *base,
+
+ read_proc_t read_proc,
+ void * data) { return NULL; }
+extern inline struct proc_dir_entry *create_proc_info_entry(const char
*name,
+ mode_t mode, struct proc_dir_entry *base, get_info_t *get_info)
+ { return NULL; }
+
+extern inline struct proc_dir_entry *proc_symlink(const char *name,
+ struct proc_dir_entry *parent,char *dest) {return NULL;}
+extern inline struct proc_dir_entry *proc_mkdir(const char *name,
+ struct proc_dir_entry *parent) {return NULL;}
extern inline void remove_proc_entry(const char *name, struct
proc_dir_entry *parent) {};
@@ -485,7 +508,5 @@
extern struct proc_dir_entry proc_root;
#endif /* CONFIG_PROC_FS */
-
-#define proc_mkdir(buf, us
[PATCH] 2.4.0 proc_fs for 2.2.18
Alan Cox wrote:
>
> > Why is 2.2.18 proc_fs.c different than both 2.2.17 and 2.4.0? Cox, would
> > you accept a patch that makes 2.2.18 define create_proc_info_entry and
> > related functions the same way that 2.4.0 does?
>
> Send me a diff and I'll be happy to
Here it is, both inlined and as an attachment. It's been tested;
compiles, boots, works. Let me know what you think.
-M
--- linux-2.2.18pre25-VIRGIN/include/linux/proc_fs.hFri Dec 8 14:57:08
2000
+++ zinux/include/linux/proc_fs.h Fri Dec 8 17:57:05 2000
@@ -262,6 +262,12 @@
#define PROC_SUPER_MAGIC 0x9fa0
+typedefint (read_proc_t)(char *page, char **start, off_t off,
+ int count, int *eof, void *data);
+typedefint (write_proc_t)(struct file *file, const char *buffer,
+ unsigned long count, void *data);
+typedef int (get_info_t)(char *, char **, off_t, int, int);
+
/*
* This is not completely implemented yet. The idea is to
* create an in-memory tree (like the actual /proc filesystem
@@ -287,24 +293,17 @@
gid_t gid;
unsigned long size;
struct inode_operations * ops;
- int (*get_info)(char *, char **, off_t, int, int);
+ get_info_t *get_info;
void (*fill_inode)(struct inode *, int);
struct proc_dir_entry *next, *parent, *subdir;
void *data;
- int (*read_proc)(char *page, char **start, off_t off,
-int count, int *eof, void *data);
- int (*write_proc)(struct file *file, const char *buffer,
- unsigned long count, void *data);
+ read_proc_t *read_proc;
+ write_proc_t *write_proc;
int (*readlink_proc)(struct proc_dir_entry *de, char *page);
unsigned int count; /* use count */
int deleted;/* delete flag */
};
-typedefint (read_proc_t)(char *page, char **start, off_t off,
- int count, int *eof, void *data);
-typedefint (write_proc_t)(struct file *file, const char *buffer,
- unsigned long count, void *data);
-
extern int (* dispatch_scsi_info_ptr) (int ino, char *buffer, char
**start,
off_t offset, int length, int inout);
@@ -433,15 +432,21 @@
/*
* generic.c
*/
+extern struct proc_dir_entry *proc_symlink(const char *,
+ struct proc_dir_entry *, const char *);
+extern struct proc_dir_entry *proc_mkdir(const char *,struct
proc_dir_entry *);
+
struct proc_dir_entry *create_proc_entry(const char *name, mode_t mode,
struct proc_dir_entry *parent);
void remove_proc_entry(const char *name, struct proc_dir_entry
*parent);
-#define create_proc_info_entry(n, m, b, g) \
- { \
- struct proc_dir_entry *r = create_proc_entry(n, m, b); \
- if (r) r->get_info = g; \
- }
+extern inline struct proc_dir_entry *create_proc_info_entry(const char
*name,
+ mode_t mode, struct proc_dir_entry *base, get_info_t *get_info)
+{
+ struct proc_dir_entry *res=create_proc_entry(name,mode,base);
+ if (res) res->get_info=get_info;
+ return res;
+}
/*
* proc_tty.c
@@ -470,12 +475,18 @@
return NULL;
}
-#define create_proc_info_entry(n, m, b, g) \
- { \
- struct proc_dir_entry *r = create_proc_entry(n, m, b); \
- if (r) r->get_info = g; \
- }
-
+extern inline struct proc_dir_entry *create_proc_read_entry(const char
*name,
+ mode_t mode, struct proc_dir_entry *base,
+
+ read_proc_t read_proc,
+ void * data) { return NULL; }
+extern inline struct proc_dir_entry *create_proc_info_entry(const char
*name,
+ mode_t mode, struct proc_dir_entry *base, get_info_t *get_info)
+ { return NULL; }
+
+extern inline struct proc_dir_entry *proc_symlink(const char *name,
+ struct proc_dir_entry *parent,char *dest) {return NULL;}
+extern inline struct proc_dir_entry *proc_mkdir(const char *name,
+ struct proc_dir_entry *parent) {return NULL;}
extern inline void remove_proc_entry(const char *name, struct
proc_dir_entry *parent) {};
@@ -485,7 +496,5 @@
extern struct proc_dir_entry proc_root;
#endif /* CONFIG_PROC_FS */
-
-#define proc_mkdir(buf, usbdir)create_proc_entry(buf, S_IFDIR, usbdir)
#endif /* _LINUX_PROC_FS_H */
diff -r -u -x CVS -x *.o linux-2.2.18pre25-VIRGIN/fs/proc/generic.c
zinux/fs/proc/generic.c
--- linux-2.2.18pre25-VIRGIN/fs/proc/generic.c Fri Dec 8 14:57:07 2000
+++ zinux/fs/proc/generic.c Fri Dec 8 17:58:34 2000
@@ -246,6 +246,65 @@
return 0;
}
+struct proc_dir_entry *proc_symlink(const char *name,
+ struct proc_dir_entry *parent, const char *dest)
+{
+ struct proc_dir_entry *ent = NULL;
+ const char *fn = name;
+ int len;
+
+ if (
2.2.18 vs 2.4.0 proc_fs.c
Why is 2.2.18 proc_fs.c different than both 2.2.17 and 2.4.0? Cox, would
you accept a patch that makes 2.2.18 define create_proc_info_entry and
related functions the same way that 2.4.0 does?
2.2.17:
does not define this
2.2.18:
#define create_proc_info_entry(n, m, b, g) \
{ \
struct proc_dir_entry *r = create_proc_entry(n, m, b); \
if (r) r->get_info = g; \
}
2.4.0:
extern inline struct proc_dir_entry *create_proc_info_entry(const char
*name,
mode_t mode, struct proc_dir_entry *base, get_info_t *get_info)
{
struct proc_dir_entry *res=create_proc_entry(name,mode,base);
if (res) res->get_info=get_info;
return res;
}
-
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/
ext2 sparse superblocks
I'm looking for documentation on Ext2's support for sparse superblocks. Canvasing search engines gets me the same two references to tune2fs and the dac960. I've also looked in /usr/doc and /usr/src/linux/Documentation without success. What it the method uses to reduce the number of superblocks? How are they laid out before vs after sparse_super is enabled? Any caveats? Thanks. -M - 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: Advanced Linux Kernel/Enterprise Linux Kernel
"Richard B. Johnson" wrote: > Relating some "nine goals of 'Enterprise Computing'" to Multics is > the bullshit. Funny, I got those off the "Multics FAQ" page. -M - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Michael Rothwell wrote: > > Mike Dresser wrote: > > > What's that $0.02 worth after 35 years of inflation? > > About $6 Sorry.. six times a much... not six dollars. Which means $0.02 circa 1965 is 'worth' $0.12 today, given an average annual devaluation of the currency of 5.2% since 1965. -M - 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: Advanced Linux Kernel/Enterprise Linux Kernel
"Richard B. Johnson" wrote: > Multics??? [..] way too many persons on this list who know the history of > Unix to try this BS. So, you're saying their nine goals were bullshit? Multics had a lot of problems. But it did a lot of ground-breaking. Perhaps you should reply to the nine goals, or the general topic of "Enterpriseness," rather than merely express your irrelevant hatred for Multics. - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Mike Dresser wrote: > What's that $0.02 worth after 35 years of inflation? About $6 - 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: Advanced Linux Kernel/Enterprise Linux Kernel
One historically significant "Enterprise" OS is Multics. It had nine major goals. Perhaps we should think about how Linux measures up to these 1965 goals for "Enterprise Computing." 1) Convenient remote terminal use. Telnet, ssh, X windows, rsh, vnc, "screen," ethernet, serial, etc. I think we have this one. 2) Continuous operation analogous to power & telephone services. No way. Multics could have a whole bank of memory fail and keep running. You could add CPUs, memory and IO devices while it was running without interrupting users' work. Of course, a lot of this cannot be accomplished due to the brain-dead hardware designs (especially PC) prevalent today. However, Linux does not have any support for this type of facility. I recently saw a patch to let Linux use partially bad memory. This is a step in the right direction. The ability to scale the system while on-line is extremely valuable. 3) A wide range of system configurations, changeable without system or user program reorganization. See comments in #2. Plus, the recent two-kernel-monte, linux-from-linux type stuff would be especially excellent if it will allow the kernel to be upgraded on the fly. If it could save state and have the new kernel take over, that would rock. On a smaller scale, allowing this for modules would be good. This would allow the upgrade of nic drivers, etc. The GKHI would also be invaluable if it would allow the replacement/augmentation of certain other subsystems on the fly -- such as the scheduler, VFS, etc. 4) A high reliability internal file system. Ext2 + bdflush + kupdated? Not likely. To quote the Be Filesystems book, Ext2 throws safety to the wind to achieve speed. This also ties into Linux' convoluted VM system, and is shot in the foot by NFS. We would need minimally a journaled filesystem and a clean VM design, probably with a unified cache (no separate buffer, directory entry and page caches). The Tux2 Phase Trees look to be a good step in the direction as well, in terms of FS reliability. The filesystem would have to do checksums on every block. Some type of mirroring/clustering would be good. And the ability to grow filesystems online, and replace disks online, would be key. If your disks are getting old, you may want to pre-emptively replace them with faster, newer, larger ones with more MTBF left. 5) Support for selective information sharing. Linux has a rather poor security model -- the Unix one. It needs ACLs no only on filesystem objects, but on other OS features as well; such as the ability to use network interfaces, packet types, display ACLs, console ACLs, etc. If there's a function, it probably needs an ACL. 6) Hierarchical structures of information for system administration and decentralization of user activities. See #5. Linux really does not support delgation of authority well. There's one user who can reconfigure/admin the system: root. Tools like sudo only make you root for a moment, and don't inherently limit you to that one activity. ACLs on most if not all system attributes and objects would go a long way towards decentralized but safe administration. 7) Support for a wide range of applications. Well... anything wih source or compiled for the Linux ABI. A microkernel-type architecture with servers would provide a lot more of this. See QNX, NT, Mach. 8) Support for multiple programming environments & human interfaces. Many languages are supported by Linux. This is good. Linux has two humnan interfaces: CLI and X Windows guis. I'm not sure what could be added, except for voice input. 9) The ability to evolve the system with changes in technology and in user aspirations. Ties ties into #2 and #3and #5. Otherwise, rewrites of the Linux kernel and userspace accomplish this. Unfortunately, that requires taking the system, or minimally its applications, down. Just some thoughts from 35 years ago. Please add your $0.02. -M - 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: anyone compiled 2.2.17 on RH7 successfully?
GCCLOC=`which gcc` rm `echo $GCCLOC` ln -s `which kgcc` `echo $GCCLOC` ... repeat for g++ -M Corisen wrote: > > thanks for the info. i've kgcc installed during RH7 installation. i've > checked the version to be 2.91.66. i've used the following 2 methods with > kgcc but it won't even allow me to compile: > 1. make CC=kgcc zImage > 2. change the CC=gcc to CC=kgcc in Makefile > > the "make CC=kgcc zImage" process reports the following error messages: > > In file included from init/main.c:15: > /usr/i386-glibc21-linux/include/linux/proc_fs.h:283: parse error before > `mode_t' > /usr/i386-glibc21-linux/include/linux/proc_fs.h:283: warning: no semicolon > at end of struct or union > /usr/i386-glibc21-linux/include/linux/proc_fs.h:284: warning: data > definition has no type or storage class > /usr/i386-glibc21-linux/include/linux/proc_fs.h:285: parse error before > `uid' > /usr/i386-glibc21-linux/include/linux/proc_fs.h:285: warning: data > definition has no type or storage class > /usr/i386-glibc21-linux/include/linux/proc_fs.h:286: parse error before > `gid' > /usr/i386-glibc21-linux/include/linux/proc_fs.h:286: warning: data > definition has no type or storage class > /usr/i386-glibc21-linux/include/linux/proc_fs.h:289: parse error before > `off_t' > /usr/i386-glibc21-linux/include/linux/proc_fs.h:290: warning: `struct inode' > declared inside parameter list > /usr/i386-glibc21-linux/include/linux/proc_fs.h:290: warning: its scope is > only this definition or declaration, > /usr/i386-glibc21-linux/include/linux/proc_fs.h:290: warning: which is > probably not what you want. > /usr/i386-glibc21-linux/include/linux/proc_fs.h:293: parse error before > `off_t' > /usr/i386-glibc21-linux/include/linux/proc_fs.h:296: warning: `struct file' > declared inside parameter list > /usr/i386-glibc21-linux/include/linux/proc_fs.h:300: parse error before `}' > /usr/i386-glibc21-linux/include/linux/proc_fs.h:302: parse error before > `off_t' > /usr/i386-glibc21-linux/include/linux/proc_fs.h:305: warning: `struct file' > declared inside parameter list > /usr/i386-glibc21-linux/include/linux/proc_fs.h:308: parse error before > `off_t' > /usr/i386-glibc21-linux/include/linux/proc_fs.h: In function > `proc_scsi_register': > /usr/i386-glibc21-linux/include/linux/proc_fs.h:344: dereferencing pointer > to incomplete type > /usr/i386-glibc21-linux/include/linux/proc_fs.h:345: dereferencing pointer > to incomplete type > /usr/i386-glibc21-linux/include/linux/proc_fs.h: In function > `proc_scsi_unregister': > /usr/i386-glibc21-linux/include/linux/proc_fs.h:359: dereferencing pointer > to incomplete type > /usr/i386-glibc21-linux/include/linux/proc_fs.h:362: `NULL' undeclared > (first use in this function) > /usr/i386-glibc21-linux/include/linux/proc_fs.h:362: (Each undeclared > identifier is reported only once > /usr/i386-glibc21-linux/include/linux/proc_fs.h:362: for each function it > appears in.) > /usr/i386-glibc21-linux/include/linux/proc_fs.h:363: dereferencing pointer > to incomplete type > /usr/i386-glibc21-linux/include/linux/proc_fs.h:365: dereferencing pointer > to incomplete type > /usr/i386-glibc21-linux/include/linux/proc_fs.h:368: sizeof applied to an > incomplete type > .many more lines > .many more lines > > - Original Message - > From: David Relson <[EMAIL PROTECTED]> > To: Corisen <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Tuesday, November 14, 2000 9:58 AM > Subject: Re: anyone compiled 2.2.17 on RH7 successfully? > > > Corisen, > > > > RedHat 7.0's version of gcc, known as gcc 2.96, is incompatible with the > > kernel's code. Preprocessor changes cause the problem you encountered. > It > > also has some defects in how it optimizes code that would cause the kernel > > to run incorrectly. > > > > The 7.0 distribution includes an older version of gcc, known as kgcc (for > > kernel gcc), that compiles code correctly and can be used for kernel > > compilation. Install the rpm and go for it! > > > > David > > > > At 08:44 PM 11/13/00, Corisen wrote: > > >has anyone running RedHat7(with kernel 2.2.16, gcc 2.96, kgcc 2.91.66) > > >complied 2.2.17 kernel successfully? > > > > > >i've downloaded the source and gunzip/untar to /root/linux-2.2.17 > > > > > >1. make menuconfig (ok) > > >2. make dep (ok) > > >3. make zImage > > >===> lots of warning message > > >===> error: checksum.S:231 badly punctuated parameter list in #define > > >===> error: checksum.S:237 badly punctuated parameter list in #define > > > > > >4. make CC=kgcc zImage > > >===> snapshot of errors reported: > > >In file included from init/main.c:15: > > >/usr/i386-glibc21-linux/include/linux/proc_fs.h:283: parse error before > > >`mode_t' > > >/usr/i386-glibc21-linux/include/linux/proc_fs.h:283: warning: no > semicolon > > >at end of struct or union > > >/usr/i386-glibc21-linux/include/linux/proc_fs.h:284: warning: data > > >definition has no type or storage class > > >/usr/i386-glibc21-linux/include/linux/proc_fs.h:285: pa
Re: latest 2.2.18-X patch?
Thanks everyone!
I've discovered that it works with my USB scanner, but the IBMCAM
doesn't work at all with the usb-uhci driver. It works once with the
uhci driver. Subsequent access using xawtv causes instantaneous lock-up.
No oops, nothing. Just freezes the entire system. Not even the keyboard
responds (can't toggle capslock, etc). Needless to say, magic sysrq
didn't work.
I've got another machine; I'll see if I can get a serial port dump to
report.
This was with 2.2.17 + pre-patch-2.2.18-21 on an Athlon 600.
-M
"Dunlap, Randy" wrote:
>
> ftp.??.kernel.org/pub/linux/kernel/v2.2
> for linux-2.2.17.tar.{gz,bz2}
> and then ftp.??.kernel.org.pub/linux/kernel/people/alan/2.2.18pre
> for pre-patch-2.2.18-21.{gz,bz2}
>
> Yes (USB backport).
>
> ~Randy_
> |randy.dunlap_at_intel.com503-677-5408|
> |NOTE: Any views presented here are mine alone|
> |& may not represent the views of my employer.|
> ---
>
> > From: Michael Rothwell [mailto:[EMAIL PROTECTED]]
> >
> > Where's the best place to get the latest 2.2.18 kernel? And does it
> > include the USB backport?
> > -
-
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/
latest 2.2.18-X patch?
Where's the best place to get the latest 2.2.18 kernel? And does it include the USB backport? - 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] Generalised Kernel Hooks Interface (GKHI)
Lars Marowsky-Bree wrote: > And I am still very fond of the idea of crash dumping to a network server ;-) I second that. Serial can be slow, and has that pesky cable-length limit... - 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] Generalised Kernel Hooks Interface (GKHI)
Matti Aarnio wrote: > On Wed, Nov 08, 2000 at 04:35:33PM -0500, Michael Rothwell wrote: > > Sounds great; unfortunately, the core group has spoken out against a > > modular kernel. > > Really ? > > $ /sbin/lsmod > Module Size Used by > [...] > soundcore 4336 4 [es1371] Really. That the kernal has loadable modules does not mean that it is modular. -M - 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: [bug] kernel panic related to reiserfs, 2.4.0-test11-pre1 and 3.6.18
David Ford wrote: > With kdb, after the panic happens, I can hit 'sr s' then 'g', it will > OOPS (process sendmail) then continue. Without kdb, I am SOL and have > to hit the power button. sysrq won't react. Debugger good. - 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] Generalised Kernel Hooks Interface (GKHI)
Alexander "see figure 1" Viro wrote: > Sorry. You don't "embed" the patch. You either get it accepted or not. > Or you fork the tree and then it's officially None Of My Problems(tm). Sounds like a good idea. -M - 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: Kernel 2.2.17 bug found
Tim Waugh wrote: > You forgot to 'cd .' Look for "pebsak" messages in /var/log/syslog ;) - 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] Generalised Kernel Hooks Interface (GKHI)
Alan Cox wrote: > RTLinux is hardly a fork. UcLinux is a fork, it has its own mailing list, web > site and everything. Post 2.4 I'm still very interested in spending time merging > the 2.4 uc and the main tree. I think it can be done and they are doing it in > a way that leads logically to this. And how would a hypothetical Advanced Linux Kernel Project be different? Set aside the GKHI and the issue of binary-only hook modules; how would an "enterprise" fork be any different than RT or UC? It'll go off, change and add some things, and then perhaps be merged back in later. In the meantime, developers who want to add "enterpriseness" to Linux will have an outlet and won't have to simply gripe on this list anymore. And users who want an "enterprise" kernel can get one. -M - 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] Generalised Kernel Hooks Interface (GKHI)
Alexander Viro wrote: > > Figure 1? > > Use search engine. On google "See Figure 1" brings the thing in the first > 5 hits. http://www.google.com/search?q=See+Figure+1&btnG=Google+Search -> http://spiffy.cso.uiuc.edu/~kline/Stuff/see-figure-1.html -> http://spiffy.cso.uiuc.edu/~kline/Stuff/f-you.gif ... http://www.google.com/search?q=See+Figure+1&btnG=Google+Search -> http://www.physics.ohio-state.edu/~bcd/humor/figure1.html ... How utterly typical of you, Viro. -M - 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] Generalised Kernel Hooks Interface (GKHI)
Alexander Viro wrote: > > On Thu, 9 Nov 2000, Michael Rothwell wrote: > > > Same as before -- freedom and low cost. The primary advantae of Linux > > over other OSes is the GPL. > > Now, that's more than slightly insulting... Well, it wasn't meant to be. I imagine RMS would make the same type of statement -- Linux is libre, therefore superior. There's a number of OSes that have advantages of Linux in some area; Solaris can use more processors; QNX is real-time, smaller and still posix; Windows has better application support (i.e., more of them); MacOS has better color and font management. But, Linux is free. Let's say for a moment that Linux was exactly the same as Solaris, technically. Linux would be superior because it is licensed under the GPL, and is free; whereas Solaris would not be. > The problem with the hooks et.al. is very simple - they promote every > bloody implementation detail to exposed API. Sorry, but... See Figure 1. > It won't fly. Figure 1? -M - 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] Generalised Kernel Hooks Interface (GKHI)
Paul Jakma wrote: > > On Thu, 9 Nov 2000, Michael Rothwell wrote: > > > Why? I think the IBM GKHI code would be of tremendous value. It would > > make the kernel much more flexible, and for users, much more friendly. > > No more patch-and-recompile to add a filesystem or whatever. There's no > > reason to hamstring their efforts because of the possibility of binary > > modules. The GPL allows that, right? > > no gpl definitely does not alow binary modules. Well, then, problem solved. > afaik linus allows binary modules in most cases. And since an "Advanced Linux Kernel Project" wouldn't be a Linus kernel, what then? Would they have the same discretion as Linus? Would Linus' exception apply to them? - 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] Generalised Kernel Hooks Interface (GKHI)
Lars Marowsky-Bree wrote: > And we already refuse to support those kernels - your point being? Who says you would support theirs? My point is, forks have been made in the past and are useful for the people that use them, and prevent "pollution" of the common kernel with hghly specialized modifications. uCLinux and RTLinux are two examples. > Making this "commonplace" is a nightmare. Go away with that. It would be a third major fork (AFAIK), not a first, and not a nightmare. Are RTLinux and uclinux nightmares? How much do they impact your life? > I want their solving of their problems not to create problems for me though. How would it create problems for you? And as a separate question, why should anyone care if it does? Part of the freedom guaranteed by the GPL is the ability for anyone to fork a codebase for their own use. And because it's all GPL code, with thoroughly divirsified copyright assignment, they will be releasing any mods under GPL as well. The ones the Linus likes, he can adapt and merge into the common kernel. If he doesn't like them, he can ignore them. Incidentally, I hear that a Utah company is going to position an older Unix kernel with Linux compatibility added and possibly a GNU userspace as "Enterprise Linux." Would you prefer that, or something actually based on the Linux codebase? -M - 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] Generalised Kernel Hooks Interface (GKHI)
Christoph Rohland wrote: > If we really need a special enterprise tree lets do > it without module tricks. Why? I think the IBM GKHI code would be of tremendous value. It would make the kernel much more flexible, and for users, much more friendly. No more patch-and-recompile to add a filesystem or whatever. There's no reason to hamstring their efforts because of the possibility of binary modules. The GPL allows that, right? So any developer of binary-only extensions using the GKHI would not be breaking the license agreement, I don't think. There's lots of binary modules right now -- VMWare, Aureal sound card drivers, etc. I understand and agree with your desire for full source for everything, but I disagree that we should artificially limit people's ability to use Linux to solve their problems. - 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] Generalised Kernel Hooks Interface (GKHI)
Christoph Rohland wrote: > If we would not allow binary only modules I would not have such a big > problem with that... I'm not sure how you would do that. > I understand that the one size fits all approach has some limitations > if you want to run on PDAs up to big iron. But a framework to overload > core kernel functions with modules smells a lot of binary only, closed > source, vendor specific Linux on high end machines. Since Linux is GPL, how would you stop this? > And then I don't see the value of Linux anymore. Same as before -- freedom and low cost. The primary advantae of Linux over other OSes is the GPL. I think and Advanced Linux Kernel PRoject would be a good idea for a number of reasons. It would give "Enterprise" users their own special kernel, just like the microcontroller and real-time guys have. It would also provide a parallel development track for Linux that could provide real competition and value to the Linus-version kernel. The "Enterprise" machines that IBM, HP and SGI would target aren't all S/390s; there would be significant overlap of their low end with Linus' high end, I think. Like 8+-way SMP servers. -M - 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] Generalised Kernel Hooks Interface (GKHI)
Sounds great; unfortunately, the core group has spoken out against a modular kernel. Perhaps IBM should get together with SGI, HP and other interested parties and start an Advanced Linux Kernel Project. Then they can run off and make their scalable, modular, enterprise kernel and the Linus Version can always merge back in features from it. -M [EMAIL PROTECTED] wrote: > > We've just release version 0.6 of Generalised Kernel Hooks Interface (GKHI) > see the IBM Linux Technology Centre's web page DProbes link: > http://oss.software.ibm.com/developerworks/opensource/linux > > Some folks expressed an interest in this type of facility recently in > discussions concerning making call-backs from the kernel to kernel modules. > > Here's the abstract for this facility. With this intend to modularise our > RAS offerings, in particular DProbes, so that they can be applied > dynamically without having to be carried as excess baggage. > > Abstract: > Generalised Kernel Hooks Interface (GKHI) is a generalised facility for > placing hooks or exits in arbitrary kernel locations. It enables many > kernel enhancements, which are otherwise self-contained, to become > loadable kernel modules and retain a substantial degree of independence > from the kernel source. This affords advantages for maintenance and > co-existence with other kernel enhancements. The hook interface allows > multiple kernel modules to register their exits for a given hook, in order > to receive control at that hook location. Multiple hooks may be defined > within the kernel and a singe kernel module may register exits to use > multiple hooks. When hook exits register they may specify co-existence > criteria. Hooks may be placed in kernel modules as well as the kernel > itself with the proviso that the modules with hooks are loaded before the > gkhi hook interfacing module. A hook exit receives control as if called > from the code in which the hook is located. Parameters may be passed to a > hook exit and may be modified by an exit. For more information down-load > the tarball. > > Note: GHKI is in late beta test - we currently do not support SMP, that > will occur soon. We also plan to support dynamic hook definition as little > later on so that kernel modules may dynamically register hooks for other > kernel modules to use. > > Richard Moore - RAS Project Lead - Linux Technology Centre (PISC). > > http://oss.software.ibm.com/developerworks/opensource/linux > Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 > IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK > > - > 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/ - 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: Linux 2.2.18pre20
Hello? -M Michael Rothwell wrote: > > Alan Cox wrote: > > > > > On Tue, Nov 07, 2000 at 09:02:36PM -0500, Michael Rothwell wrote: > > > > 64-bit printk. > > > > > > Please consider this one Alan, if not for v2.2.18, then at least for > > > v2.2.19pre1. > > > > Nobody has explained why we even need it. > > Alan Cox wrote: > > > > Why do we need it ? > > To print 64-bit debugging output on 32-bit machines. I personally need > it to aid with development of a 64-bit filesystem. We're maintaining our > own 2.2.17 patched kernel here, but I figure that other people can make > use of 64-bit printk in their efforts as well. > > Perhaps a better question would be, why reject it? 2.4 supports 64-bit > printk, right? It would be nice to have it on 2.2 as well, as it may be > a while before 2.4 is widely used in production machines. > > -M - 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: [RANT] Linux-IrDA status
Linus Torvalds wrote: > and these people expect me to reply, sending long explanations of why I > don't like them? After they did nothing of the sort for the code they > claim should have been applied? Nada. Did you say that to them? I'm not saying you're wrong; but did you tell them that? It might make your life easier if you make a faq on "how to get your code accepted" and another on "how to get your code rejected." Then you could send people off to read those, and maybe even site a "violates #6" or whatever. > Get a grip. Help a little. -M - 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: [RANT] Linux-IrDA status
Linus Torvalds wrote: > > On Tue, 7 Nov 2000, Michael Rothwell wrote: > > > > Linus, can you post reasons why you keep ignoring^W rejecting the IrDA > > patch? > > Basically, whatever Alan rants, I've not seen the patches all that many > times at all. > > Also, I've never seen much in the form of explanation, and at least the > last patch I saw just the first screenful was so off-putting that I just > went "Ok, I have real bugs to fix, I don't need this crap". > > Linus Like what? I'm not sure what you're saying here. It seems that the pople writing the IrDA code have gotten no feedback from you as to why their patch is never accepted -- could you clarify? They're apparently putting a lot of effort into writing and fixing IrDA for Linux, and have become very discouraged at the lack of feedback. "Crap" the code may be, but it seems like it would be a good idea to at least say something substantive about why their code keeps getting rejected. - 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: Linux 2.2.18pre20
Alan Cox wrote: > > > On Tue, Nov 07, 2000 at 09:02:36PM -0500, Michael Rothwell wrote: > > > 64-bit printk. > > > > Please consider this one Alan, if not for v2.2.18, then at least for > > v2.2.19pre1. > > Nobody has explained why we even need it. Alan Cox wrote: > > Why do we need it ? To print 64-bit debugging output on 32-bit machines. I personally need it to aid with development of a 64-bit filesystem. We're maintaining our own 2.2.17 patched kernel here, but I figure that other people can make use of 64-bit printk in their efforts as well. Perhaps a better question would be, why reject it? 2.4 supports 64-bit printk, right? It would be nice to have it on 2.2 as well, as it may be a while before 2.4 is widely used in production machines. -M - 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: Linux 2.2.18pre20
64-bit printk.
-M
Alan Cox wrote:
>
> Ok last call for 2.2.18. The PS/2 cases I've looked at all appear to be
> ghost PS/2 interfaces created due to the USB support fooling programs.
diff -B --unidirectional-new-file --exclude-from=DiffExcludeList --recursive --unified
linux-2.2.16/include/asm-alpha/div64.h linux/include/asm-alpha/div64.h
--- linux-2.2.16/include/asm-alpha/div64.h Wed Dec 31 19:00:00 1969
+++ linux/include/asm-alpha/div64.h Fri Aug 11 20:04:18 2000
@@ -0,0 +1,14 @@
+#ifndef __ALPHA_DIV64
+#define __ALPHA_DIV64
+
+/*
+ * Hey, we're already 64-bit, no
+ * need to play games..
+ */
+#define do_div(n,base) ({ \
+ int __res; \
+ __res = ((unsigned long) (n)) % (unsigned) (base); \
+ (n) = ((unsigned long) (n)) / (unsigned) (base); \
+ __res; })
+
+#endif
diff -B --unidirectional-new-file --exclude-from=DiffExcludeList --recursive --unified
linux-2.2.16/include/asm-arm/div64.h linux/include/asm-arm/div64.h
--- linux-2.2.16/include/asm-arm/div64.hWed Dec 31 19:00:00 1969
+++ linux/include/asm-arm/div64.h Fri Aug 11 20:05:41 2000
@@ -0,0 +1,14 @@
+#ifndef __ASM_ARM_DIV64
+#define __ASM_ARM_DIV64
+
+/* We're not 64-bit, but... */
+#define do_div(n,base) \
+({ \
+ int __res; \
+ __res = ((unsigned long)n) % (unsigned int)base;\
+ n = ((unsigned long)n) / (unsigned int)base;\
+ __res; \
+})
+
+#endif
+
diff -B --unidirectional-new-file --exclude-from=DiffExcludeList --recursive --unified
linux-2.2.16/include/asm-i386/div64.h linux/include/asm-i386/div64.h
--- linux-2.2.16/include/asm-i386/div64.h Wed Dec 31 19:00:00 1969
+++ linux/include/asm-i386/div64.h Fri Aug 11 20:06:05 2000
@@ -0,0 +1,17 @@
+#ifndef __I386_DIV64
+#define __I386_DIV64
+
+#define do_div(n,base) ({ \
+ unsigned long __upper, __low, __high, __mod; \
+ asm("":"=a" (__low), "=d" (__high):"A" (n)); \
+ __upper = __high; \
+ if (__high) { \
+ __upper = __high % (base); \
+ __high = __high / (base); \
+ } \
+ asm("divl %2":"=a" (__low), "=d" (__mod):"rm" (base), "0" (__low), "1"
+(__upper)); \
+ asm("":"=A" (n):"a" (__low),"d" (__high)); \
+ __mod; \
+})
+
+#endif
diff -B --unidirectional-new-file --exclude-from=DiffExcludeList --recursive --unified
linux-2.2.16/include/asm-m68k/div64.h linux/include/asm-m68k/div64.h
--- linux-2.2.16/include/asm-m68k/div64.h Wed Dec 31 19:00:00 1969
+++ linux/include/asm-m68k/div64.h Fri Aug 11 20:06:57 2000
@@ -0,0 +1,35 @@
+#ifndef _M68K_DIV64_H
+#define _M68K_DIV64_H
+
+/* n = n / base; return rem; */
+
+#if 1
+#define do_div(n, base) ({ \
+ union { \
+ unsigned long n32[2]; \
+ unsigned long long n64; \
+ } __n; \
+ unsigned long __rem, __upper; \
+ \
+ __n.n64 = (n); \
+ if ((__upper = __n.n32[0])) { \
+ asm ("divul.l %2,%1:%0" \
+ : "=d" (__n.n32[0]), "=d" (__upper) \
+ : "d" (base), "0" (__n.n32[0]));\
+ } \
+ asm ("divu.l %2,%1:%0" \
+ : "=d" (__n.n32[1]), "=d" (__rem) \
+ : "d" (base), "1" (__upper), "0" (__n.n32[1])); \
+ (n) = __n.n64; \
+ __rem; \
+})
+#else
+#define do_div(n,base) ({ \
+ int __res; \
+ __res = ((unsigned long) n) % (unsigned) base; \
+ n = ((unsigned long) n) / (unsigned) base; \
+ __res; \
+})
+#endif
+
+#endif /* _M68K_DIV64_H */
diff -B --unidirectional-new-file --exclude-from=DiffExcludeList --recursive --unified
linux-2.2.16/include/asm-mips/div64.h linux/include/asm-mips/div64.h
--- linux-2.2.16/include/asm-mips/div64.h Wed Dec 31 19:00:00 1969
+++ linux/include/asm-mips/div64.h Fri Aug 11 20:41:49 2000
@@ -0,0 +1,20 @@
+/* $Id: div64.h,v 1.1.2.1 2000/08/12 00:41:49 zapman Exp $
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+#ifndef _ASM_DIV6
continuing VM madness
Should kswapd and klogd ever get "do_try_to_free_pages failed"? when this happens my machine is destabilized, and pauses briefly from time to time before locking up or otherwise becoming inert. This is 2.2.16+USB. Nov 7 14:51:36 cartman kernel: VM: do_try_to_free_pages failed for kswapd... Nov 7 15:46:39 cartman kernel: VM: do_try_to_free_pages failed for panel... Nov 7 15:46:39 cartman kernel: VM: do_try_to_free_pages failed for klogd... Nov 7 15:46:40 cartman kernel: VM: do_try_to_free_pages failed for identd... Nov 7 15:46:40 cartman kernel: VM: do_try_to_free_pages failed for mini_commander_... Nov 7 15:46:40 cartman kernel: VM: do_try_to_free_pages failed for gpm... Nov 7 15:46:40 cartman kernel: VM: do_try_to_free_pages failed for mozilla-bin... Nov 7 15:46:40 cartman kernel: VM: do_try_to_free_pages failed for mozilla-bin... Nov 7 15:46:40 cartman kernel: VM: do_try_to_free_pages failed for init... Nov 7 15:46:40 cartman kernel: VM: do_try_to_free_pages failed for xntpd... Nov 7 15:46:40 cartman kernel: VM: do_try_to_free_pages failed for nmbd... Nov 7 15:46:40 cartman kernel: VM: do_try_to_free_pages failed for vmware... Nov 7 15:46:40 cartman kernel: VM: do_try_to_free_pages failed for vmware... - 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: working nfs v3 for linux?
Okay, how about the nfsv3 kernel patch for 2.2.17? Does anyone know how well (reliably) it works in client and server mode? Thanks! -M - 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: working userspace nfs v3 for linux?
Aaron Denney wrote: > I am not aware of any userspace NFSv3 server. Your best bet would > probably to take the v2 server and mutate it. Why do you want this beast? So I can use Linux rather than Solaris 7 and the Solstice Disk Suite, which performs like crap thanks to UFS, and the Linux NFS v2 implementation. -M - 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: working userspace nfs v3 for linux?
Andi Kleen wrote: > > On Wed, Nov 01, 2000 at 02:59:05PM -0500, Michael Rothwell wrote: > > Is there a working userspace nfs v3 server for linux? > > Yes, just install user mode linux and use its v3 knfsd server. Does anyone have any suggestions that aren't jokes, don't require a 2.4 kernel and will work? - 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/
working userspace nfs v3 for linux?
Is there a working userspace nfs v3 server for linux? -M - 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/
