Linux-Development-Sys Digest #167, Volume #8 Sat, 23 Sep 00 14:13:17 EDT
Contents:
Re: Sokets in Linux (Andi Kleen)
the way of changing 'counter' in sched.c (Changxun Wu)
Re: Any GIF decoders designed for small devices?????? (William McBrine)
Re: Kernel space vs User space (Christopher Browne)
Re: /proc/*/stat: parsing the file name (Lew Pitcher)
Re: restore from scsi tape (Peter Pointner)
Compressed File System (aslin)
Re: new windowing system (D J Hawkey Jr)
kmalloc failure ("Anil Prasad")
Re: Compressed File System (Bernhard Brueck)
kmalloc with 64k ("Anil Prasad")
Re: new windowing system (Alexander Viro)
Re: kmalloc with 64k (Kaz Kylheku)
Re: the way of changing 'counter' in sched.c (Kaz Kylheku)
Re: new windowing system (Kasper Dupont)
Re: /proc/*/stat: parsing the file name (Kasper Dupont)
Re: the way of changing 'counter' in sched.c (Kasper Dupont)
----------------------------------------------------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Sokets in Linux
Date: 23 Sep 2000 03:04:02 +0200
[EMAIL PROTECTED] (Rick Ellis) writes:
> In article <[EMAIL PROTECTED]>,
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> >To get reliable errno you have to set errno to 0 first.
>
> No, you just have to not use the value in errno unless you get an
> indication of an error being report, i.e. -1 being returned.
That's a dangerous approach, because often library functions tend to
generate hidden errors you never know about. Setting errno to 0
is much safer.
-Andi
------------------------------
From: Changxun Wu <[EMAIL PROTECTED]>
Subject: the way of changing 'counter' in sched.c
Date: Fri, 22 Sep 2000 23:37:25 -0400
I'm reading the kernel/sched.c of kernel-2.2.17's source, which is about
the process scheduling.
I am confused by the code at line 844:
p->counter = (p->counter >> 1) + p->priority;
Why should we change the variable 'counter' like that? Thanks.
------------------------------
From: William McBrine <[EMAIL PROTECTED]>
Subject: Re: Any GIF decoders designed for small devices??????
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Date: Sat, 23 Sep 2000 04:36:02 GMT
In comp.os.linux.misc MikeC <[EMAIL PROTECTED]> wrote:
> Does anybody know of good sources for GIF decoders written
> specifically for small mobile devices like cellular handsets, screen
> sizes up to 200x200 pixels?
Interesting question. I know that, back in the day, CompuServe sponsored
development of GIF viewers for a wide variety of computers, including low-
end 8-bit home systems like the Commodore 64, etc. Some of those systems
have even seen active development recently. You might look to those user
communities for what you need, though it will most likely be written in
assembly language rather than C.
--
William McBrine <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Kernel space vs User space
Reply-To: [EMAIL PROTECTED]
Date: Sat, 23 Sep 2000 04:46:26 GMT
In our last episode (Fri, 22 Sep 2000 22:10:22 +0000),
the artist formerly known as Karl Heyes said:
>In article <8qegmb$1pp$[EMAIL PROTECTED]>, "Nera"
><[EMAIL PROTECTED]> wrote:
>> Can me get more resource when running the code in kernel space
>> other = than user space?
>
>resource? CPU, memory, disk ? generally no.
Well, _in theory_, kernel mode gives the ability to get direct access
to _anything_ on the whole system before user mode gets access to it.
But if you expect user mode to actually _work_, and if you want to
"play by the rules," it is vastly _less_ convenient to "play well" and
use great amounts of resources in kernel mode.
A "for instance" being that in the kernel, the _proper_ way to
allocate memory involves using kmalloc() rather than malloc(), where
kmalloc() has considerably more restrictions in order that the kernel
behave well.
--
(concatenate 'string "cbbrowne" "@" "acm.org")
<http://www.hex.net/~cbbrowne/lsf.html>
"The reality of the software business today is that if you find
something that can make you ridiculously rich, then that's something
that Microsoft is going to take away from you." -- Max Metral
------------------------------
From: Lew Pitcher <[EMAIL PROTECTED]>
Subject: Re: /proc/*/stat: parsing the file name
Date: Fri, 22 Sep 2000 21:21:00 -0400
WATM wrote:
>
> First, let me tell you that you probably found the reason why the second
> argument is enclosed in ()'s.
>
> /proc/self/stat is intended to be parsed with
> scanf("%d (%s) %c ...", ...);
>
> Notice the () around the second argument.
For his example, it won't do any good.
The %s "Matches a sequence of non-white-space characters" (according
to "man scanf" and my recollection of the C standard). In his example,
the input would be "(a) b)" (where "a) b" is the name of his program),
so a scanf("(%s)",...) would
1) match the format string's '(' to the data's '(',
2) extract the following "a)" in response to the %s format,
3) skip the next whitespace character, and
4) attempt to match the format string's ')' to the input data 'b', and
fail
At that point, scanf will stop, returning the "number of input items
assigned,
which can be fewer than provided for, or even zero, in the event of
a
matching failure"
> You should probably study scanf a little better :-)
You should definately take your own advice.
> --Bruno
>
> Alan J Rosenthal wrote:
> >
> > Greetings. It seems to me that the /proc/*/stat file in linux is unparseable.
> > I created an executable which just cats /proc/self/stat, and I called it
> > 'a) b' (hm, I just realized I could have simply renamed a copy of 'cat'),
> > and its output was then (line wrapped)
> >
> > 6592 (a) b) R 4579 6592 4579 34821 6592 0 20 0 79 0 0 1 0 0 17 0 0 0 890837136
> > 1110016 81 2147483647 134512640 134513938 3221223936 3221223704 1074532452 0 0
> > 0 0 0 0 0 17 0
> >
> > Is there a way to parse this (re field #2)? I'm interested in a later field,
> > but I do have to skip the earlier stuff to get it. Unless I want to parse
> > from the end, blech.
> >
> > 'ps' seems to get it right... does it get its information from somewhere
> > else? It *does* refer to the /proc/<pid>/stat file in the source code,
> > and it has a big scanf (in accordance with the man page proc(4)) which I'm
> > sure has to fail in the case of spaces in the file name... or am I wrong?
> > I didn't spend the time to determine what it uses the result of that scanf
> > for but it does seem to get everything right about the process named with
> > parentheses and spaces in the file name, e.g. it gets its start time right
> > (which is what I'm looking for).
> >
> > This is running with redhat's kernel 2.2.16-3, if it makes a difference,
> > which I assume it doesn't.
> >
> > thanks,
> > ajr
--
Lew Pitcher
Master Codewright and JOAT-in-training
------------------------------
From: Peter Pointner <[EMAIL PROTECTED]>
Subject: Re: restore from scsi tape
Date: 23 Sep 2000 09:10:36 +0200
Hi Sam,
sam <[EMAIL PROTECTED]> wrote:
> Hi
> Now,I use a scsi tape and the tar command to backup directory.
> ex: tar /dev/st0 /var/lib/mysql
You could use
tar cf /dev/st0 /var/lib/mysql
(And you could choose a more appropriate newsgroup for questions like
this. c.o.l.d.s is about system _development_).
Note that this command will overwrite the tape from its current position.
> Then, how to restore these directories from the tape.
cd /; tar xpf /dev/st0
> Another problem, can I mount the scsi tape(/dev/st0) like the cdrom?
st is a character device, so you don't mount it. It's good for backups,
bad for random access.
Peter
------------------------------
From: aslin <[EMAIL PROTECTED]>
Subject: Compressed File System
Date: 23 Sep 2000 07:45:21 GMT
I'm looking for compressed file system,
to store text docs (generaly HTML pages with images, of course)
with large amout of files.
A there any solutions ?
Does ext2 support features like this ?
--
=======================
Szczepan Konieczny
e-mail: [EMAIL PROTECTED]
=======================
------------------------------
Reply-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] (D J Hawkey Jr)
Subject: Re: new windowing system
Crossposted-To: comp.os.linux.x,comp.windows.x
Date: Sat, 23 Sep 2000 10:12:11 GMT
In article <8q3vl6$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Alexander Viro) writes:
> In article <[EMAIL PROTECTED]>,
> Christopher Browne <[EMAIL PROTECTED]> wrote:
>
> [SNIP]
>
> Having the graphical console in the kernel doesn't strike me as something
> too horrible. And yes, it can be easily made network-transparent, so it's
> not localhost-only.
I'm no Xpert, nor OS architect, but this piqued my interest.
IMHO, one of the biggest flaws in the later "generations" of MS-Windoze(tm)
was moving the GUI into "protected" (kernel?) space. They did it just to try
and speed things up (if you recall, Windoze(tm) was incredibly slow prior to
this, as opposed to the current abysmally slow. It also (again, IMHO) is one
reason why the PC community has to go through the cyclic upgrade path (that
and the notion of un-checked, or lack-of-clearinghoused, DLL growth).
The GUI belongs in user space. Most of the OS should also live in user space
(yes, I'm a micro-kernel fan). It makes the entire system more stable. I ran
a MetroLink X server tailored for a lean-and-mean micro-kernelled OS on a
'486-100 for years, and it ran rings around Windoze(tm) on newer/bigger PCs.
Did I use GNOME? No. KDE? No. Did I need them? No. Do I now? No. This is to
say that the user/SysAdmin has to realize that if you want lean-and-mean,
you stick with apps that also are lean-and-mean.
I could make the argument that, at least on local connections, the transport
medium is the least of concerns when one ponders performance. Code bloat and
inefficiencies would be the place to look first. Remote connections? Well,
painting pixels across a modem link is just rather silly, isn't it? I don't
take the possibility seriously, anyway. But on a Gb LAN? Sure, no sweat.
Just my two cents' worth,
Dave
--
______________________ ______________________
\__________________ \ D. J. HAWKEY JR. / __________________/
\________________/\ [EMAIL PROTECTED] /\________________/
http://www.visi.com/~hawkeyd/
------------------------------
From: "Anil Prasad" <[EMAIL PROTECTED]>
Subject: kmalloc failure
Date: 23 Sep 2000 13:16:09 GMT
i tried to allocate physical memory of 128k by calling kmalloc function,
passing parameter of (128k-1)bytes, but the computer hanged. when i made it
to 32k , the computer rebooted,
i am using 2.2.14-5.0 kernel.
same was the case with get_free_pages() service..
------------------------------
From: Bernhard Brueck <[EMAIL PROTECTED]>
Subject: Re: Compressed File System
Date: 23 Sep 2000 12:40:46 GMT
aslin <[EMAIL PROTECTED]> wrote:
> I'm looking for compressed file system,
> to store text docs (generaly HTML pages with images, of course)
> with large amout of files.
> A there any solutions ?
> Does ext2 support features like this ?
No, not out of the box. But a patch exists to do that.
http://e2compr.memalpha.cx/e2compr/
Bernhard
--
=============================================================================
Dipl.-Inform. Univ. Bernhard Brueck email: [EMAIL PROTECTED]
------------------------------
From: "Anil Prasad" <[EMAIL PROTECTED]>
Subject: kmalloc with 64k
Date: 23 Sep 2000 13:46:22 GMT
hi!
this is related to previous problem,
when i tried to allocate 64k of physical memory by calling
kmalloc(64*1024-1, GFP_KERNEL), it allocated the memory, also wrote the
memory, but when i read it, it gave Ayeei message, saying interrupt
handlers has been killed..
what could be the reason??
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: comp.os.linux.x,comp.windows.x
Subject: Re: new windowing system
Date: 23 Sep 2000 10:36:20 -0400
In article <%l%y5.964$[EMAIL PROTECTED]>,
D J Hawkey Jr <[EMAIL PROTECTED]> wrote:
>In article <8q3vl6$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Alexander Viro) writes:
>> In article <[EMAIL PROTECTED]>,
>> Christopher Browne <[EMAIL PROTECTED]> wrote:
>>
>> [SNIP]
>>
>> Having the graphical console in the kernel doesn't strike me as something
>> too horrible. And yes, it can be easily made network-transparent, so it's
>> not localhost-only.
>
>I'm no Xpert, nor OS architect, but this piqued my interest.
>
>IMHO, one of the biggest flaws in the later "generations" of MS-Windoze(tm)
>was moving the GUI into "protected" (kernel?) space. They did it just to try
Erm... There is some difference between /dev/tty and termcap+curses+panel+...
The latter clearly has no place in the kernel, the former... Why not?
Same for the graphics. Graphical console (no notion of window, focus, GC,
etc.) is not a GUI, it's not even a window system. The point being, window
system can be done as a multiplexor over the graphical console. In userspace,
indeed. And it can expose the interface identical to the console one -
set of device nodes for each window, with the same semantics as the real
console. Yes, userland filesystem - nothing new about that. That way it
doesn't have to deal with talking to bare hardware, running suid-root, etc.
>and speed things up (if you recall, Windoze(tm) was incredibly slow prior to
>this, as opposed to the current abysmally slow. It also (again, IMHO) is one
I don't do Windows, so no recollections here. And frankly, I don't care.
I've seen Cutler's code in RSX and I have no desire to deal with his
misdesigned abortions again. Sorry. He got no taste at all. Solid
engineering - maybe, elegance - no fscking way in hell.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: kmalloc with 64k
Reply-To: [EMAIL PROTECTED]
Date: Sat, 23 Sep 2000 15:47:46 GMT
On 23 Sep 2000 13:46:22 GMT, Anil Prasad <[EMAIL PROTECTED]> wrote:
>hi!
>this is related to previous problem,
>when i tried to allocate 64k of physical memory by calling
>kmalloc(64*1024-1, GFP_KERNEL), it allocated the memory, also wrote the
>memory, but when i read it, it gave Ayeei message, saying interrupt
>handlers has been killed..
>what could be the reason??
You must not call kmalloc with a GFP_KERNEL flags argument in the context of an
interrupt service routine. You must use GFP_ATOMIC, which grabs memory in a
non-blocking, interrupt-safe way way from a pool that is reserved for just
these allocations.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: the way of changing 'counter' in sched.c
Reply-To: [EMAIL PROTECTED]
Date: Sat, 23 Sep 2000 15:50:41 GMT
On Fri, 22 Sep 2000 23:37:25 -0400, Changxun Wu <[EMAIL PROTECTED]> wrote:
>I'm reading the kernel/sched.c of kernel-2.2.17's source, which is about
>the process scheduling.
>
>I am confused by the code at line 844:
> p->counter = (p->counter >> 1) + p->priority;
>
>Why should we change the variable 'counter' like that? Thanks.
Because we still don't trust that compilers can handle divisions by power of
two constants efficiently? :)
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.x,comp.windows.x
Subject: Re: new windowing system
Date: Sat, 23 Sep 2000 19:07:26 +0200
[EMAIL PROTECTED] wrote:
>
> > >Your PC must be faster than mine. Of course almost any PC would
> > >be as mine is a 486. For me, every microsecond wasted counts
> > >since they all up quickly.
> >
> > There winds up being LOTS of things that "add up quickly," including:
> > - Number of bytes of memory consumed;
> > - Number of I/O requests
> > - Quantity of video RAM in use
> >
> > 486 VLB versus just about anything using PCI is quite a big deal.
> > PCI is a whopping lot faster, _particularly_ for graphics.
>
> Ummm...ummm...VLB? Golly, I ain't even got that.
> We're talking V-G-A here. I really need some
> efficiency badly.
>
> > Well, _immediately_ upon having a network connection involved
> > (e.g. - Ethernet), there's a fair bit of overhead over a straight
> > function call.
>
> Can you quantify that?
>
> > The _big_, _atrocious_ problem there is that if all this stuff
> > gets pushed into the kernel, that means that:
> >
> > - every time an application touches the screen, there has to be a
> change
> > from user mode to kernel mode,
>
> That also happens every time a byte gets sent over a socket, no?
>
It is posible to read/write more than one byte with a single
syscall. Transfering large amounts of data with one syscall
pr. byte would be toooo ineficient. Userspace libraries
normally use 4KB buffers.
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: /proc/*/stat: parsing the file name
Date: Sat, 23 Sep 2000 19:31:00 +0200
Alan J Rosenthal wrote:
>
> Greetings. It seems to me that the /proc/*/stat file in linux is unparseable.
> I created an executable which just cats /proc/self/stat, and I called it
> 'a) b' (hm, I just realized I could have simply renamed a copy of 'cat'),
> and its output was then (line wrapped)
>
> 6592 (a) b) R 4579 6592 4579 34821 6592 0 20 0 79 0 0 1 0 0 17 0 0 0 890837136
> 1110016 81 2147483647 134512640 134513938 3221223936 3221223704 1074532452 0 0
> 0 0 0 0 0 17 0
>
> Is there a way to parse this (re field #2)? I'm interested in a later field,
> but I do have to skip the earlier stuff to get it. Unless I want to parse
> from the end, blech.
>
> 'ps' seems to get it right... does it get its information from somewhere
> else? It *does* refer to the /proc/<pid>/stat file in the source code,
> and it has a big scanf (in accordance with the man page proc(4)) which I'm
> sure has to fail in the case of spaces in the file name... or am I wrong?
> I didn't spend the time to determine what it uses the result of that scanf
> for but it does seem to get everything right about the process named with
> parentheses and spaces in the file name, e.g. it gets its start time right
> (which is what I'm looking for).
>
> This is running with redhat's kernel 2.2.16-3, if it makes a difference,
> which I assume it doesn't.
>
> thanks,
> ajr
I have been wondering about the same.
(I need to find the controlling tty.)
I think the best solution probably will
be to load the entire file and search
from the end until you find a ')'.
It is a little tricky to load the file
since you don't know the size, you
could set an upper limit or use realloc
for allocating memory.
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: the way of changing 'counter' in sched.c
Date: Sat, 23 Sep 2000 19:42:32 +0200
Changxun Wu wrote:
>
> I'm reading the kernel/sched.c of kernel-2.2.17's source, which is about
> the process scheduling.
>
> I am confused by the code at line 844:
> p->counter = (p->counter >> 1) + p->priority;
>
> Why should we change the variable 'counter' like that? Thanks.
This is a fading exponential average.
The p->priority might be changing so
much that using this directly would
cause problems.
On the other hand we still want to
react on changes so using the average
from the start of the process until
now would not be a good idea either.
In such cases an easy solution which
is in most cases quite good is an
exponential fading avereage.
It is computed with floats like:
newavg = (1.0-c)*oldavg + c*value;
where c is a constant between 0.0 and
1.0 which control how fast to react
on changes.
We would prefer a solution using
integers instead of floats, in the
particular case that is done by
storing 2 times average instead of
avereage itself, c i set to 0.5.
The following calculations shows
how to update the variable
containing 2*avg
newavg = (1.0-0.5)*oldavg + 0.5*value
2*newavg = 2*((1.0-0.5)*oldavg + 0.5*value)
2*newavg = (2*oldavg)*0.5 + value
2*newavg = (2*oldavg)>>1 + value
Hope this helps.
--
Kasper Dupont
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
