Linux-Development-Sys Digest #178, Volume #6 Sat, 26 Dec 98 02:14:15 EST
Contents:
Re: Threads and PIDs ("Bjorn Wesen")
Arabic & Linux ([EMAIL PROTECTED])
Re: Registry for Linux - Bad idea (Michal Mosiewicz)
Re: Registry for Linux - Bad idea (Victor Lowther)
Re: Registry for Linux - Bad idea (Robert Krawitz)
compaq presario 1640 cdrom device driver (Scott Savarese)
Re: Shared PCI interrupts (RH 5.2 -- 2.0.36) (Kenneth Crudup)
Re: Shared PCI interrupts (RH 5.2 -- 2.0.36) (Kenneth Crudup)
----------------------------------------------------------------------------
From: "Bjorn Wesen" <[EMAIL PROTECTED]>
Subject: Re: Threads and PIDs
Date: Sat, 26 Dec 1998 04:14:27 +0100
Jody Hagins wrote in message <01be2f38$1a272680$29f782cc@lewstherin>...
>Why, when I spin threads, do I see them as processes in "ps?"
Because you see all processes with ps, and a "thread" is a process in Linux.
I guess a more intelligent ps would be able to recognize which are threads
to each other and which are independant processes.
>If this is the case, how can the processes share the same address space?
>What's the benefit? Why do I not see any system calls with strace when
>creating a thread?
It just depends on how they are created. If you split a process into two
threads, you effectively make another process but instead of giving it it's
own memory you give it the same memory as the old one. Check out the clone()
system call, which given the right flag will let the new process share the
VM with the parent (CLONE_VM or something it's called).
I don't know why you don't see it in the strace. Maybe you did see the fork
or clone but didn't know which flags to look for.
>I have alot of other questions as well, but maybe I can get a pointer to
>some definitive literature on Linux threads.
I'll pass on that since I've never programmed with linux threads. I just
know how clone() works :) (both fork() and clone() calls do_fork inside the
kernel, just with different user control on flags).
/Bjorn
------------------------------
From: [EMAIL PROTECTED]
Subject: Arabic & Linux
Date: Sat, 26 Dec 1998 03:16:36 GMT
A friend and I are about to develop an Arabic language extention to Linux...
We don't want to reinvent the wheel... So is anyone here is developing
something along these general lines? Or heard/seen anything similar?
-- Raad Al-Hamdan
-- Jeddah, Saudi Arabia
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Michal Mosiewicz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Sat, 26 Dec 1998 04:49:04 +0100
Robert Krawitz wrote:
>[...]
> > b) kernel space managment to accomplish ownership of database records
> > and access rights (not only per user, but also per application)
>
> Why must it be in the kernel? That's just adding more bloat to the
> kernel for something that can be done perfectly well in user space.
What bloat? How do you feel your kernel is bloated by (stupid) things
like, for example, consoles. They bloating you beautifully pure,
lightweight kernel just to assure that you friend can't trash on your
console and there is no anarchy in access to your screen. That's a
bloat. Note how much bloat it appeared in the kernel since it came out.
This is a kind of change-o-foby. I remember those discussions on things
like KGI. Why is that so, that if there is anything similiar to
something in Windows, there is always a natural 'I vote - no!' from many
Linux users. After time resistance gets weaker and somebody notices some
good sides of the solution. But precious time is wasted on disregarding
every idea which is similiar to what we know from Windows.
> This is not an issue of personal preferences. It's an issue of being
> able to recover the system with minimal tools when something goes
> wrong.
My personal acceptance for global persistent storage is based on
experience. I have some projects, that store their configurations in the
database. And the system reconfigures online, sometimes several times
per second. And I have no problems with recovering. It just recovers
it's configuration with the rest of the database with a single command
typed at the command line. But still I would like to be able to
reconfigure the core of apache in the same manner I do it for my
modules. Moreover it would be much easier to recover the whole system
from the database.
If you need more informations about how easy it's recover the system
with chaotic configuration management, just go to a bigger ISP (using
Linuks of course). In many cases things like passwords, aliases, domains
and similiar configuration files are only shadows of some central
database. That's why many ISP servers react on account changes in an
hour or even a day. It's becouse they are not able to update those
shadows more frequently with accurate effectivness. Ask them if it's
easier to restore all informations from one central source, or to check
if all the information is consistent.
>And a simple text editor like ed is much less likely to go
> wrong than some fancy graphical tool that requires X to be running and
> has who knows what buffer overrun bugs that get triggered by some bit
> getting flipped deep in the bowels of the index.
What I had written had nothing to do with fancy graphical tools.
> Humans are a lot more adaptable than computers. If I misspell this
> worrd, I can see it very easily and fix it, if it's in a readable text
> file. If I flip a bit in the index, unless the tools using the
> database are very clever, this error won't be caught.
I don't argue with this argumentation cause it's irrational. I never
said that admin should type things in hex.
>[...]
> Whereas currently with Linux if it won't boot because there's some
> configuration problem, I just slip in my handy Tom's root/boot disk,
> mount the offending root filesystem, hunt around for the problem, and
> back in business.
Good you have such a small system to manage.
>[...]
> YaST, on SuSE, has an interesting approach of its own. It's basically
> a terminal-driven front end to a batch of config files, and when you
> make a change and then tell it to go ahead, it reruns the necessary
> configuration scripts. Red Hat's control panel is similar, and I
> think it sends the SIGHUP's itself.
Sure there are tools to easier this stuff. As I said, on my servers
ordinary configuration files tend to play a secondary role. Most of the
things are being done in the central database, then shadowed to config
files. Of course, if anybody is too tied to his vi - go ahead. But
please, this is irrational argument, that every configuration must be
done using text tool. Next irrational argument is that the system state
description should be decentralised - it's naturally best if we can
backup/restore the whole using single commands.
And finally I should clarify, that my point is not to complain about
that I have no registry (since I have some partial forms of that where I
need it), but I _do_ complain about some people's hard minds. Arguments
like:
1) It's wrong becouse it's built in windows.
2) It's wrong becouse it's not compatible with my favourite text editor.
3) It's wrong becouse it might fail, which indirectly means that it will
fail for sure.
4) It's wrong becouse it's not made of chocolate.
are these kind of arguments enough to dump every idea to /dev/null. Even
the brightest.
Mike
--
WWW: http://www.lodz.pdi.net/~mimo tel: Int. Acc. Code + 48 42 2148340
add: Michal Mosiewicz * Bugaj 66 m.54 * 95-200 Pabianice * POLAND
------------------------------
From: [EMAIL PROTECTED] (Victor Lowther)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 26 Dec 1998 04:14:41 GMT
On Tue, 22 Dec 1998 01:59:27 Michal Mosiewicz <[EMAIL PROTECTED]> wrote:
>Richard RUDEK wrote:
>> [...]
>> I agree, a registry for linux is a bad idea. But I don't see how a standard
>> configuration procedure "naturally suggests a single file".
>
>Why is it a bad idea?
>
>Or, let me put it this way - what is better than a single database
>optimised for persistent configuration storage?
>
>In fact people are too tied to those fancy configuration files. They
>start to complain when it comes to start some netscape or some another
>configuration-hungry program. Just look at how your system (I mean
>Linux) starts. It takes a minute or so to boot up. Much of this time is
>spent on setting up the state of kernel. It takes hundreds of files to
>be open, tens of programs to be started and a lot of scripts to be
>interpreted. It consumes a lot of time. Unnecessary time.
Er, the state of the kernel is already set up and useable once you hit
/sbin/init. There are other things that are set up during the boot
sequence, but the kernel is stable and useable at that point.
>Some people say that is dangerous to have a single database
>configuration database. Isn't it dangerous to have a single filesystem?
>I'm far from suggesting that it should be a single file - it might be a
>single device. Sometime this database would be accessible as a set of
>text files (for text-addicted people) but the point is that a common
>filesystem is not necessary optimal database.
The main reason that flat text is nice IMHO is fault-tolerance. Try
rm -rf /etc on a unix box, rebooting the system and see what happens.
Try the equivalent (deltree c:\windows\system.dat) on a 98 box and see
how far you get. Which one is more recoverable?
>
>Mike
>
>--
>WWW: http://www.lodz.pdi.net/~mimo tel: Int. Acc. Code + 48 42 2148340
>add: Michal Mosiewicz * Bugaj 66 m.54 * 95-200 Pabianice * POLAND
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 25 Dec 1998 23:33:57 -0500
Note that I'm primarily a system programmer by background and a
pessimist by temperament. I don't see the glass half empty, I see the
microscopic cracks in the glass that are slowly leaking :-) So
robustness of a system is very important to me.
Michal Mosiewicz <[EMAIL PROTECTED]> writes:
> Robert Krawitz wrote:
> >[...]
> > > b) kernel space managment to accomplish ownership of database records
> > > and access rights (not only per user, but also per application)
> >
> > Why must it be in the kernel? That's just adding more bloat to the
> > kernel for something that can be done perfectly well in user space.
>
> What bloat? How do you feel your kernel is bloated by (stupid) things
> like, for example, consoles. They bloating you beautifully pure,
> lightweight kernel just to assure that you friend can't trash on your
> console and there is no anarchy in access to your screen. That's a
> bloat. Note how much bloat it appeared in the kernel since it came out.
Consoles can't be implemented in user space. It's bad enough that
console switching doesn't work from X (yet). Something like this
doesn't need kernel support. There's no other obvious pressing reason
for it to be in the kernel.
I'm not opposed to adding things to the kernel. I'm opposed to
*gratuitously* adding things to the kernel. You haven't made a good
case for putting this in the kernel.
> This is a kind of change-o-foby. I remember those discussions on things
> like KGI. Why is that so, that if there is anything similiar to
> something in Windows, there is always a natural 'I vote - no!' from many
> Linux users. After time resistance gets weaker and somebody notices some
> good sides of the solution. But precious time is wasted on disregarding
> every idea which is similiar to what we know from Windows.
I'm not familiar with KGI, so I can't comment.
> > This is not an issue of personal preferences. It's an issue of being
> > able to recover the system with minimal tools when something goes
> > wrong.
>
> My personal acceptance for global persistent storage is based on
> experience. I have some projects, that store their configurations in the
> database. And the system reconfigures online, sometimes several times
> per second. And I have no problems with recovering. It just recovers
> it's configuration with the rest of the database with a single command
> typed at the command line.
That's fine, but unless you can be positive that you can get the
system to a state where you can type that command, it's useless. If
the system can't boot if the database isn't running, and can't be
recovered with a simple external tool that fits on a floppy, then this
is doing no good. You can't ignore chicken and egg problems here!
(The reason I specify "fits on a floppy" is not arbitrary -- a 1.44M
floppy is the common medium of external storage that essentially every
PC has. If 10 years from now every PC has a 200 MB floppy or whatnot,
I'll be happy if the recovery tool fits on that. Until then, I want
to be able to recover from a floppy.)
But still I would like to be able to
> reconfigure the core of apache in the same manner I do it for my
> modules. Moreover it would be much easier to recover the whole system
> from the database.
But what if I don't want to recover my whole system? What if I need
to make a change just to be able to boot the thing?
> If you need more informations about how easy it's recover the system
> with chaotic configuration management, just go to a bigger ISP (using
> Linuks of course). In many cases things like passwords, aliases, domains
> and similiar configuration files are only shadows of some central
> database. That's why many ISP servers react on account changes in an
> hour or even a day. It's becouse they are not able to update those
> shadows more frequently with accurate effectivness. Ask them if it's
> easier to restore all informations from one central source, or to check
> if all the information is consistent.
Fine. I'm well aware of that. And perhaps it's better that there be
a bit more latency in account changes if it's going to improve system
stability and recoverability.
(Things like NIS work reasonably well, particularly the simpler
variants. I have, however, seen machines that won't boot when NIS
isn't running. That's inexcusable. Normally, the machine should boot
to the point where an administrator can get a superuser shell even if
everything external is down. I'm aware that that is not true in some
secure environments, where denial of service is preferable to allowing
hostile intrusion, but that's not the subject here).
> >And a simple text editor like ed is much less likely to go
> > wrong than some fancy graphical tool that requires X to be running and
> > has who knows what buffer overrun bugs that get triggered by some bit
> > getting flipped deep in the bowels of the index.
>
> What I had written had nothing to do with fancy graphical tools.
Fair enough, but an RDBMS is still more complex than a text editor,
and more likely to go wrong.
> > Humans are a lot more adaptable than computers. If I misspell this
> > worrd, I can see it very easily and fix it, if it's in a readable text
> > file. If I flip a bit in the index, unless the tools using the
> > database are very clever, this error won't be caught.
>
> I don't argue with this argumentation cause it's irrational. I never
> said that admin should type things in hex.
Not at all. Suppose there's a bug in the RDBMS, or an alpha particle
flips a bit somewhere...
> >[...]
> > YaST, on SuSE, has an interesting approach of its own. It's basically
> > a terminal-driven front end to a batch of config files, and when you
> > make a change and then tell it to go ahead, it reruns the necessary
> > configuration scripts. Red Hat's control panel is similar, and I
> > think it sends the SIGHUP's itself.
>
> Sure there are tools to easier this stuff. As I said, on my servers
> ordinary configuration files tend to play a secondary role. Most of the
> things are being done in the central database, then shadowed to config
> files.
Notice that the shadowing to config files works. I have no objection
to this, nor does anyone else I've seen post to this thread. We're
all in favor of tools to more easily manage this stuff, but we want to
seem them designed carefully and defensively.
I prefer text files simply because there are ALTERNATE ways to manage
them if something breaks down. If an RDBMS with binary storage breaks
down, there's nothing else there to maintain it. If a text file
maintained by an RDBMS breaks down, a human can go in and fix it with
an unrelated tool -- a text editor. That's why I prefer textual
configuration files -- redundancy.
> 1) It's wrong becouse it's built in windows.
Not the issue. I believe that the Windows registry is inherently
fragile, and I don't want Linux to make the ame mistake.
> 2) It's wrong becouse it's not compatible with my favourite text editor.
Let's understand why I think this is an issue -- not so much because I
prefer editing text (although I do), but because I want a *redundant*
means of repair. Text files make this easy. Binary file formats make
this hard.
> 3) It's wrong becouse it might fail, which indirectly means that it will
> fail for sure.
Well, again, let's look at the consequences of failure. A system that
can't boot is usually (but not always!) more critical than an
application that won't run correctly, but even so it's better if this
can be recovered from.
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: [EMAIL PROTECTED] (Scott Savarese)
Subject: compaq presario 1640 cdrom device driver
Date: 26 Dec 1998 05:25:57 GMT
I have a compaq 1640 laptop with a CD-ROM and I am trying to get the CDROM to
actually work. It spits out a bunch of errors whenever I try to mount anything
or doing anything with it. I have a feeling that the problem is that the cdrom
is not completely ATAPI complient, although Compaq tech support says it is
(funny if it was then why does Win98 need a special driver).
So I want to write a device driver to get it to work. I posted an E-mail to
this newsgroup before asking advice on how to write one, and somebody's advice
was to send this post.
I would like to know if somebody has already written a driver that solves this
problem, in which case can I get a copy, or are currently developing now. If
this is the case could I offer my assistance in testing or development.
If somebody else as written a driver for a similar problem in another
computer, can I get a copy of the driver to see a basic idea of what has to
get done...
Thanks for the help,
Scott
--
------------------------------
From: [EMAIL PROTECTED] (Kenneth Crudup)
Subject: Re: Shared PCI interrupts (RH 5.2 -- 2.0.36)
Date: 26 Dec 1998 01:26:28 -0500
In article <[EMAIL PROTECTED]>,
Neal Becker <[EMAIL PROTECTED]> says:
>1. Only some (most?) linux drivers will tolerate shared interrupts.
True. They have to be written (or modified, as I did 'back in .33's
NE2K driver) to support shared interrupts, and the changes in the 2.1
kernels makes that even easier. I was pointing out that the devices
this guy's got (Tulip Ethernet and both OSS and ALSA Ensoniq AudioPCI)
support IRQ sharing for PCI after 2.0.35 .
>2. You probably can convince your BIOS not to use the same interrupt for
>everything if you fiddle with the settings.
I did this on purpose, mostly for my own amusement, but secondarily to
educate those who say it can't be done.
Hell, even Win98 can handle 2x2940U, Ensoniq AudioPCI, Dec Tulip, and USB
all on the same irq.
-Kenny
--
Kenneth R. Crudup, Unix Software Consultant, Scott County Consulting
Home: | Purgatory:
8811 Colesville Rd., #509 | P.O. Box 230009 301-562-1922(H)
Silver Spring, MD 20910 | Boston, MA 02123-0009 617-422-2443(W)
------------------------------
From: [EMAIL PROTECTED] (Kenneth Crudup)
Subject: Re: Shared PCI interrupts (RH 5.2 -- 2.0.36)
Date: 26 Dec 1998 01:27:54 -0500
>> What does "not work" mean?
In article <[EMAIL PROTECTED]>,
Wolfgang Rupprecht <[EMAIL PROTECTED]> says:
>1) "ifconfig -a" doesn't indicate that an "eth0" exists.
>2) "ifconfig eth0 <anything>" comes up with an error (from memory)
> "device not configured" or something like that. Sorry for the
> vagueness. Since the ethernet isn't working the box is dual-booted
> into a different OS at the moment.
Have you got an entry for the device in /etc/conf.modules (if it's a module)?
Post your boot lines (from /var/log/messages).
-Kenny
--
Kenneth R. Crudup, Unix Software Consultant, Scott County Consulting
Home: | Purgatory:
8811 Colesville Rd., #509 | P.O. Box 230009 301-562-1922(H)
Silver Spring, MD 20910 | Boston, MA 02123-0009 617-422-2443(W)
------------------------------
** 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
******************************
