Linux-Development-Sys Digest #185, Volume #6 Mon, 28 Dec 98 12:14:03 EST
Contents:
enable and disable irq ("Gilles GRENIER")
Re: Registry for Linux - Bad idea (Stefaan A Eeckels)
Re: Kernel v2.2 (Erik de Castro Lopo)
Re: CDROM Joliet extension (H. Peter Anvin)
Re: user space drivers,why ? (Robert Kaiser)
Re: Linux Update Server? (Erwin de Beus)
Re: Linux Update Server? (Yann Vernier)
Winfast S320 video card (Frank Tiels)
Re: Registry - Already easily doable, in part. (Tristan Wibberley)
Re: ppp dialin (with VJ compression) problems with dev.kernel 2.1.132 (Marc Lefranc)
----------------------------------------------------------------------------
From: "Gilles GRENIER" <[EMAIL PROTECTED]>
Subject: enable and disable irq
Date: Mon, 28 Dec 1998 10:48:46 +0100
I'am working with a 2.0.36 kernel and when i'll try to disabled irq with:
disable_irq(int irq) (from: /asm/irq.h)
nothing happens ???
regards.
begin 666 GRENIER Gilles.vcf
M0D5'24XZ5D-!4D0-"E9%4E-)3TXZ,BXQ#0I..CM'4D5.2452.T=I;&QE<PT*
M1DXZ1U)%3DE%4B!':6QL97,-"D]21SI-241)(%-94U1%33M)3D9/4DU!5$E1
M544-"E1%3#M73U)+.U9/24-%.C T.3(Y,C4Y,# -"E1%3#M73U)+.T9!6#HP
M-#DR.3(R-#<W#0I!1%([5T]22SM%3D-/1$E.1SU154]4140M4%))3E1!0DQ%
M.CL[4&%R8R!D)V%C=&EV:70]13D@9&4@;"=A<F=I;&4],$0],$$Q,#4L=F]I
M92!C.TU/54%.4R!305)43U58.S V.S V,S<P.T9204X]#0I#10T*3$%"14P[
M5T]22SM%3D-/1$E.1SU154]4140M4%))3E1!0DQ%.E!A<F,@9"=A8W1I=FET
M/44Y(&1E(&PG87)G:6QE/3!$/3!!,3 U+'9O:64@8STP1#TP04U/54%.4R!3
M05)43U58+" P-B P-C,W,#T-"CTP1#TP049204Y#10T*14U!24P[4%)%1CM)
M3E1%4DY%5#IG9RYM<T!W86YA9&]O+F9R#0I2158Z,3DY.#$R,CA4,#DT.#0V
.6@T*14Y$.E9#05)$#0H`
`
end
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 28 Dec 1998 02:55:01 GMT
In article <[EMAIL PROTECTED]>,
Michal Mosiewicz <[EMAIL PROTECTED]> writes:
> Stefaan A Eeckels wrote:
>> [...]
>> If you analyse start-up delays for a large program (eg netscape), you'll
>> see that reading the configuration files takes negligible time compared
>
> Are you sure? I mean - is it paging the binaries that causes the delay?
> As for my machine Netscape pages in about 4-5MBs at start. Not much,
> right? On the same machine I'm able to page in the whole netscape binary
> (which normally never happens) and every library in just 5 seconds.
>
> The whole netscape starts about 30 seconds. Where is that negligible
> time your talking about? Of course Netscape's case is pretty
> exceptional. To make parsing easier Netscape often reads configuration
> files byte-by-byte. But that's a different story.
Do yourself a favour and strace -tt your netscape, once when you've
just booted the system, and once when you've just run netscape.
Analyze the results. Run strace -tt on netscape when your memory
is full, and programs have to be paged out.
On my PII/266, the time elapsed between the moment the last shared
library has been "loaded" and the moment it starts checking for
plugins and helper applications (such as nsconference) is 2.680569 seconds.
Of those 2.680569 seconds, 1.209028 are spent acquiring memory (through brk).
Checking for the plugins and checking my (rather large PATH) for the
helpers adds a further 0.164836 seconds. Reading the history.db file
(655360 bytes) is comprised in the 2.68 seconds, and takes all of
0.129760 seconds (it's probably in the cache). Checking /etc/passwd,
/etc/resolv.conf, and /etc/hosts takes a further 0.056978 seconds,
and a call to gethostbyname() takes a measly 0.006935 seconds.
There's a fair amount of dialog with the X server (0.371863 seconds)
comprised in the 2.68 seconds startup time. In effect, more than
50% of the time (1.580891 of 2.680569, or 59%) is spent doing other
things than reading configuration or history data.
The wall clock time elapsed when starting netscape on a freshly rebooted
machine is about 20 seconds (I'll reboot if you want to have exact
measurements of the various times). I grant you that a lot of the
extra seconds are dedicated to priming the cache, but don't forget
that the executable is also cached, and that it's about 4 times as
large as all the configuration and history data combined.
> Anyhow - the time spent on opening (50% missed), reading, seeking,
> closing is not negligible.
Even if you're going to eliminate *all* the time spent reading the
configuration data, you'll still spend exactly the same amount
processing it, so your net gain will probably be in the order of
50% - a total savings of a measly 0.55 seconds.
The added complexity just isn't worth it, and I stick to my guns:
You're overly concerned with micro-optimisation.
BTW, even though netscape might be reading configuration data
one byte at a time, it does so through the fopen interface, which
buffers data in user memory. It's quite efficient - just measure
it.
Take care,
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exup�ry
------------------------------
From: Erik de Castro Lopo <[EMAIL PROTECTED]>
Subject: Re: Kernel v2.2
Date: Mon, 28 Dec 1998 19:57:36 +1100
Martin Bahlinger wrote:
>
> Does anybody know, how long we've to wait for the new Linux kernel ??
It will be ready when it is ready.
> BTW: Is it called v2.2 or v3.0 ???
It is going to be called 2.2.x
Erik
--
+-------------------------------------------------+
Erik de Castro Lopo [EMAIL PROTECTED]
+-------------------------------------------------+
Windows NT : An evolutionary dead end.
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: CDROM Joliet extension
Date: 28 Dec 1998 08:50:55 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <[EMAIL PROTECTED]>
By author: David Yeung <[EMAIL PROTECTED]>
In newsgroup: comp.os.linux.development.system
>
> Does the RedHat 5.2 kernel support CDROM Joliet extension, and
> how do I know if the CDROM contains Joliet extension when I
> mount it?
>
1. Yes
2. The kernel prints a message (the dmesg command should list the
kernel messages.)
-hpa
--
PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
See http://www.zytor.com/~hpa/ for web page and full PGP public key
I am Bah�'� -- ask me about it or see http://www.bahai.org/
"To love another person is to see the face of God." -- Les Mis�rables
------------------------------
From: [EMAIL PROTECTED] (Robert Kaiser)
Subject: Re: user space drivers,why ?
Date: 28 Dec 1998 00:04:59 GMT
In article <75r39r$br4$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Roger Butenuth) writes:
> In article <75ql6q$2ru$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Robert
>Kaiser) writes:
>|>
>|> Why does the process die ? In L4, you can register so-called
>|> preemption handlers or exception handlers to deal with all kinds
>|> of reasons that could cause a process to die. Such a handler could
>|> be used to release the resource.
>
> Because some student does an error when he learns programming. Faulty
> user processes occur and should not be able to crash the system (as
> long as they have no root priveledges). These handlers help for
> programms without bugs, not for buggy programs that forgets to install
> them.
Oh, so you want 100 % fool proof device driver development ? I'm
sorry, but that won't be possible any time soon. As soon as you
give a programmer access to real hardware (which is the purpose
of a device driver), you give him/her a license to crash the system.
> Faults in drivers can crash the system, we seem to agree on that.
It does make a difference, though, wether the system gets crashed
by every silly pointer fault (which is probably the most common
mistake made by C programmers) or if such a fault just causes a
segfault in user space, leaving the rest of the system alive.
> Debugging a user level driver with DDD or something else? That changes
> the timing, as any other debugging technique, so the bug may disappear
> (I call that "Heisenbug").
So, since any debugging technique changes the timing, all debugging
is futile, right ?
Look, I have spend most of the past ten years developing device drivers
for many different UNIX flavours. I kow *exactly* what you mean with
that "Heisenbug" analogy of yours because I have seen it many times
and yet I have had countless situations where I desperately longed
for a way to use an interactive debugger on one of my drivers. I
can't believe you are seriously denying the benefit this would have.
And as for the change in timing: Any debugging method has some impact
on timing. The commonly used method of adding printk() statements to
the driver code is about the worst when it comes to timing impact.
An interactive debugger like gdb has no impact on code execution
timing at all, as long as you don't use gadgets like watchpoints.
If a program changes it's behavior when run under a debugger, then
chances are it's because the program being debugged has some kind
of race condition problem. Running the program under a debugger
may cause a bug to disappear, or it may cause a new problem to
appear that didn't manifest itself before. Such problems are
notoriously hard to pinpoint. There simply isn't a standard way
to deal with them and, depending on the nature of the particular
problem, a debugger may in fact help or hinder you in doing so.
But since a debugger is as inappropriate a method for this particular
form of bug as any other, that doesn't mean a debugger is completely
useless, does it ?
>
>|> - Message based system call mechanism: allows for re-direction
>|> of system calls across - for instance - a network. This neatly
>|> opens a path to distributed systems.
>
> This a nice feature, but difficult to implement, even with microkernels.
Well, if you say so,....
> In Linux most of the kernel is hardware/processor independent, so
> where is the point? Even many drivers are processor independent.
I don't think we are talking about the same level of portability here.
For the microkernel I have in mind a port for a new architecture should
be doable in about a man-month. I'm not sure Linux can keep up with that.
What's far more important, though, is that the amount of code shared
amoung all platforms increases. This not only means less porting
effort but also increased chances for obscure bugs to manifest
themselves (and be fixed for *all*).
>|> > I don't see major advantages in moving all drivers to user space, here
>|> > a short list of some arguments against them:
>|> >
>|> > - User level drivers can still crash the whole system.
>|>
>|> Yes, but the cances or recovering or finding the driver bug that
>|> causes the crash are better.
>
> Searching time dependent bugs in communicating processes can be really
> hard. I made this experience, it is not funny.
Nobody said it's funny. But it's certainly easier if you can
use a thread-aware HLL debugger rather than being stuck with time-
impacting printk()'s and with an environment that will crash and
need a reboot followed by a fsck after every trivial mistake.
> But where is the advantage of your microkernel? I still see the big
> disadvantage I mentioned at the top. I have seen no solution for this.
If you can only accept 100% fool proof device driver programming
as a solution, then, due to the nature of the problem, there is no
solution.
If you can't see an advantage, maybe it's because you don't want to.
Cheers
Rob
================================================================
Robert Kaiser email: rkaiser AT sysgo DOT de
SYSGO RTS GmbH
Mainz / Germany
------------------------------
From: Erwin de Beus <[EMAIL PROTECTED]>
Crossposted-To: linux.dev.kernel
Subject: Re: Linux Update Server?
Date: Mon, 28 Dec 1998 14:35:22 +0100
ncc1701d wrote:
> NNTP-Posting-Date: Sun, 27 Dec 1998 23:18:03 PDT
>
> Hi people,
> I was just wondering if there is any kind of program out there for Linux,
> RedHat in particular, that has the same functionality as the Windows Update
> Server does for Win98. I use the windows update function quite a bit and
> realized that it would be a GREAT thing to have under Linux. Glint itself
> could be the front end for the program if only there was some kind of
> central repository that would allow either an NFS type mount or if Glint
> could be modified to allow FTPing available updates. Glint already
> recognizes which patches you have installed in your system and respectfully
> hides them. This would be something that would make it easier for NEWBIES
> and experts alike to be able to update there servers automagically whenever
> a new patch/program comes out. Being that RPM is an open source type
> installation method it already has the making to be a great feature of ALL
> Linux distributions.
>
> Comments/Flames anyone?
>
> Jason
>
> PS Or am I missing something and does glint already do this?
This functionallity is in Yast, the setup program that comes with SuSe Linux
(www.suse.com).
It can update all rpm packages that are installed by comparing version numbers
with the rpms on the distribution.
The distribution can be on a CD, but it can alse reside anywhere on a
filesystem (including NFS) or on a ftp server. Updates for SuSe Linux can be
done over the internet this way from ftp.suse.com.
Regards,
Erwin de Beus
------------------------------
From: Yann Vernier <[EMAIL PROTECTED]>
Crossposted-To: linux.dev.kernel
Subject: Re: Linux Update Server?
Date: Mon, 28 Dec 1998 15:16:53 +0100
This functionality also exists in Debian, which doesn't use the RPM
format... it's much a matter of how the package management is handled in
each distribution. In Debian, there are many ways to do the job, of which
I chose to use APT. It can be used directly or as a dselect method. I
don't know what the best choice would be for Red Hat, but even if it
shares a package format it's not always a good idea to install a package
from one distribution on another (imagine installing Slackware's init,
which follows BSD style iirc, on a Red Hat system with SysV style init
scripts).
In short, it's available, but you'll have to see what matches your
distribution nicest. Glint won't run without X, which is one reason I
don't use it. Good luck, anyway.
Yann
------------------------------
From: Frank Tiels <[EMAIL PROTECTED]>
Subject: Winfast S320 video card
Date: Mon, 28 Dec 1998 16:35:52 +0100
Hello
I just bought a new videocard, the winfast s320 with riva128 chipset
(more info http://www.leadtek.com/s320.htm).
The chipset is included in the new version of slackware (3.6) but it
doesn't seems to work.
Did anyone else have the same problem allready and what driver did you
use?
Thanks for any input...
Frank Tiels (Belgium)
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: Mon, 28 Dec 1998 14:35:52 +0000
Reply-To: [EMAIL PROTECTED]
Michal Mosiewicz wrote:
>
> Tristan Wibberley wrote:
> >
> > Michal Mosiewicz wrote:
> > >
> > > Todd Knarr wrote:
> > > > [...]
> > > > True. I could speed things up there drastically, by piling all the routing
> > > > and other related stuff into a single monolithic script and dumping it in
> > > > in one big load. That, however, would be a stone bitch to administer after
> > > > it was set up. Any change would require reloading the whole thing
> > >
> > > Why reloading?
> > >
> > > By registry, I mean:
> > > a) an easily accessible database with optimised indexed storage
> > > b) kernel space managment to accomplish ownership of database records
> >
> > This sounds like a filesystem (except for the per application rights,
> > which is a little more complex, and probably unnecessary). The speed
> > problem then is probably caused by running interpreted scripts, and that
> > the files are typically less than the block size (4kb on intel?) which
> > is inefficient.
>
> Right - finally someone notices that. Per applications rights are not so
> complex, however they are not so important. What is important - each
> open operation is relatively costly. So it's good for performance to
> have less opens, and to have more informations per single file. By
> compressing more informations in a single page we make a better use of
> cache memory.
>
> By optimisation I mean something like clustering (related keys/values
> are groupped on the same pages) and indexing.
>
> Mike
You realise that with a root filesystem with 4kb blocks, you can have
this right now on your computer. I believe there is a system call to
keep stuff paged in (or you can easily implement one), then these files
stay in memory as long as your system is booted. You can pull your boot
scripts into one, executed from the mounting script left in /etc using
the '.' bash builtin. And lo, your problem is muchly solved.
The only time consuming efforts left will be where an app opens it's own
config files, with it's own specific file format. If it does that
inefficiently you get slowdown.
By the way, I noticed you snipped the comment of 'specific' verses
'general registry' later in my post. I am wondering whether you agreed
or disagreed. I've included it below:
: Actually, by letting the app have it's own file format specially for
: it's task you reduce the overhead substantially for any complex
config,
: and if the task isn't complex then the unified method is faster, but
: since it's simple cases, it's very minor (eg "ifconfig" and "route"
: would benefit if they had config files now, but they get called only
2/3
: times and work from commandline anyway which is faster still).
I think the issue also falls down with even /etc/hosts and
/etc/resolv.conf if they are preloaded and kept paged in (uses very
little memory), because they are so simple to parse. I think it also
falls down if they are not preloaded and kept paged in.
What are the other issues/uses for a registry?
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: Marc Lefranc <[EMAIL PROTECTED]>
Subject: Re: ppp dialin (with VJ compression) problems with dev.kernel 2.1.132
Date: 28 Dec 1998 15:42:48 +0100
Sion Masamune <[EMAIL PROTECTED]> writes:
> Hi there,
>
> i dunno if this is a stupid question, but howcome the vj-compression
> doesn't work with
> dev. kernel 2.1.132 ?
>
> I'm running egcs 1.1.1, libc5, pppd 2.3.4
I don't know if this is the reason, but isn't ppp-2.3.5 required for
recent development kernels ?
--
_____________________________________________________________
Marc Lefranc, Charge de Recherche au CNRS
Laboratoire de Spectroscopie Hertzienne (URA CNRS 249)
Bat P5, UFR de Physique
Universite des Sciences et Technologies de Lille
F-59655 Villeneuve d'Ascq CEDEX (FRANCE)
e-mail: [EMAIL PROTECTED] ; FAX : +33 (0)3 20 33 70 20
_____________________________________________________________
------------------------------
** 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
******************************
