Linux-Development-Sys Digest #870, Volume #6 Thu, 24 Jun 99 00:14:25 EDT
Contents:
Re: TAO: the ultimate OS (Emile van bergen)
Re: TAO: the ultimate OS (Emile van bergen)
Re: TAO: the ultimate OS (Terry Murphy)
Re: NT kernel guy playing with Linux (Arun Sharma)
Re: NT kernel guy playing with Linux ("Geoff Winans")
Now Collect2 linking fails with: multiple definition of ... ("Alan W. Jurgensen")
Re: PCI driver blues (Rajarshi Bandyopadhyay)
Re: NT kernel guy playing with Linux (Arun Sharma)
NR_OPEN & NR_FILE sucks (XuYifeng)
Re: using C++ for linux device drivers (Mario Klebsch)
Why we are still holding on to X Windows (Michael Gu)
Re: Guides to Linux Performance Tuning??? (Martin Maney)
Re: Why not C++ (John E. Davis)
Re: TAO: the ultimate OS (Frank Sweetser)
----------------------------------------------------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Thu, 24 Jun 1999 01:49:25 +0200
On 21 Jun 1999, Terry Murphy wrote:
[SNIP]
>Look at ODBC in Windows: because of this additional feature, the
>system is suddenly more flexible. You can plug any database backend
>into your program without changing a line of code. THAT is flexible.
>How could this flexibility be achieved in a system with no notion
>of a database?
Excuse me, but the _OS_ doesn't need a notion of a database, a
record management library to be used by all kinds of applications
does...! Even in the plate of spaghetti Windows is when it comes to
layering, it's done that way.
But if you want to consider a library which is used by more than one
application part of the operating system, have it your way. Let's avoid
confusion.
>>The reason UNIX doesn't have all that many features was that the
>>fundamental design is flexible. One basic example of this is the notion
>>of records in a filesystem: a inherently very non-flexible notion, that
>>results in lots of silly utilities that are very specific to some
>>things.
>
>I emphatically disagree. BECAUSE Unix does not records in the
>filesystem (and more generally, because it does not force much policy),
>each program becomes its own point tool, whose data is inaccessible to
>any other program. If you implement a database in Unix by write()'ing
>and read()'ing struct's, your data is an island: only one program can
>acess it (yes, that program CAN be a filter which can interact with the
>standard programs, but means you do need a silly utility for each file
>format, which you suggest is a bad thing).
I disagree too, but I think you can take his statement also that things
should be done at the right layer (i.e. wildcard expansion in the shell
as opposed to VMS, where every single program has the choice to expand
them itself (using f$whatever, granted) or plain refuse to accept them.
Responding to you: it's a matter of where to place the functionality. At
one point or another, you need a snippet of code able to grok a specific
data format, be it an object, a filter, a library, whatever. What we all
want to avoid is that when we have A programs and B data formats we need
A x B pieces of code (consider image formats / naive painting programs).
Now there are two approaches possible. 1. Write B libraries, one
for each data format and a uniform API and each program can use them in
a similar fashion.
Aside: if you want to view the libraries as operating system services,
okay, but I think they're not, because someone who isn't able alter the
OS itself, could conceivably be able to add a library (a system
administrator/or regular programmer as opposed to an OS designer
perhaps?).
2. write B filters, one for each data format, that convert the format to
a common denominator format (for example, image formats to postscript).
IOW, the question is between an intermediate, generalised API (code) and
an intermediate, generalised data format (data). Which is best, I don't
really know. Both could be imagined providing things like optional
capabilities and extensions and such.
The general unix philosophy seems to tend to 2, but 1 is also possible.
In Unix, its up to the _application designer_ or even the system
builder which one to choose.
I guess the problem with data formats as opposed to libraries is that a
really good filter ends up like a library if you want it to handle more
complex operations than just conversion, i.e.
echo "john/smith/broadway/543/555-1234" | db_add -f addressbook
as an hypothetical example. Also, filters are just pipes, i.e. a single
input stream and a single output streams.
But this doesn't lead to the conclusion that the whole filter idea is a
bad thing, it only shows that some things are best done in libraries.
You can have libraries in Unix. In fact, you have lots of them. The only
ones I'd actually consider part of unix itself, are libc and libm.
>If you use an ASCII format for your program, you do have access to the text
>utilities, and don't need specialized tools, but there are problems:
>the Unix tools are line oriented but complex data will necessitate more
>complex formats. AWK or PERL will help here, but that is awfully close
>to a "silly utility" for each format, since each format will require
>its own script.
Each binary format will need its own code as well to manipulate it.
Whats the difference?
>And as for systems with records having lots of silly utilities: in VMS
>there is exactly one utility to handle records in files.
'Handle' is a broad concept. AWK is a language, not an utility, IMHO.
I'm sure you didn't mean to say that one utility could handle all
operations AWK can do on textfiles, just because that utility deals with
records instead of text, or did you? ;-)
--
M.vr.gr. / Best regards,
Emile van Bergen (e-mail address: [EMAIL PROTECTED])
This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
~
~
:wq
------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Thu, 24 Jun 1999 02:15:42 +0200
On Tue, 22 Jun 1999, Vladimir Z. Nuri wrote:
>as Terry Murphy was saying, in good design
>
>requirements -> design -> detailed design -> prototype -> beta -> release
>
>or something like that..
[SNIP]
>but unix programmers do not
>think in terms of the above. instead we have, as ESR
>glorifies,
>
>code -> release -> code -> release -> code -> release
Okay, lets draw religion into this, as this is clearly an argument
between creationism and darwinism. ;-))))
But seriously, every system what needs to adapt to a changing
environment will undergo more development cycles than just one. And the
OS'ses environment changes rapidly: users on one side change, hardware
on the other side changes.
Popper (and nature) argue 'piecemeal tinkering' tends to be more
efficient than revolutionary design when it comes to adaptivity. Beauty
is something else, however, and it seems you're looking for that.
BTW, I have some ideas such as you do with Tao, but I'll save them for
some other time.
--
M.vr.gr. / Best regards,
Emile van Bergen (e-mail address: [EMAIL PROTECTED])
This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
~
~
:wq
------------------------------
From: [EMAIL PROTECTED] (Terry Murphy)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 24 Jun 1999 00:57:30 GMT
In article <[EMAIL PROTECTED]>,
Emile van bergen <[EMAIL PROTECTED]> wrote:
>Popper (and nature) argue 'piecemeal tinkering' tends to be more
>efficient than revolutionary design when it comes to adaptivity. Beauty
>is something else, however, and it seems you're looking for that.
Published studies have concluded that software engineers who follow the
design->code paradigm are more efficient and productive than those who
follow the edit->compile->test paradigm, and that the most productive
software engineers are those who spend the least amount of time in
front of a computer (and, yes, I can provide bilbiographic citations to
back this up).
-- Terry
------------------------------
From: [EMAIL PROTECTED] (Arun Sharma)
Subject: Re: NT kernel guy playing with Linux
Reply-To: [EMAIL PROTECTED]
Date: Thu, 24 Jun 1999 01:34:02 GMT
> > Only one processor (BP) can handle interrupts in SMP too. So if a
> > process is in the kernel in another processor, interrupts are not
> > handled?
>
> I don't know the details on this one. I *think* IO-APIC hardware is
> used to distribute interrupts across CPU's.
That's right. Read the Vol 3, Chapter 7 of the Pentium* manuals on
http://developer.intel.com to figure out how.
On a SMP Linux box, you can do
# cat /proc/interrupts
to see how interrupts are distributed and it's typically a very even
distribution.
-Arun
------------------------------
From: "Geoff Winans" <[EMAIL PROTECTED]>
Subject: Re: NT kernel guy playing with Linux
Date: Wed, 23 Jun 1999 19:06:34 -0700
I consider myself semi-new to the linux faith. :)
Anyway, the reentrancy is not an issue, it exists. A lot of people say it
doesn't exist, but it does.
SMP Has been TOTALLY revamped as of 2.2.x/2.3.x
All kernel's support threads, and both CPU's can now do interrupt handling.
It's all very low key stuff right now - the development team seems to be
more interested in re-doing the IO and such.
Thats where NT fails, with all his driver->driver->driver->driver passing of
"packets".. Great for it, but it lacks in power when things chew into it as
such. I use NT at home on occasion, but not to often.
I'm a Linux fanatic, I've been known to flame NT. I've yet to see my NT box
be able to run half as well as my Linux box.
~Geoff Winans
--Tech Supt.
--Campus CWIX (Cable and Wireless Internet Experience)
Holden McGroin wrote in message
<[EMAIL PROTECTED]>...
>Its fun to get into a new OS. Never mucked with Linux before. I've
>been doing NT kernel stuff for a few years.
>
>Any uplifting comments for someone new to the linux faith would be
>helpful...
>
>Read Rubini's linux dvice driver book (which seems to cover up to
>2.1.43 of linux). I must say, I'm a little disappointed in the linux's
>apparent non-reentrancy. Rubini says there's a global semaphore that
>is grabbed every time a process enters the kernel.
>
>Additionally, linux's SMP handling doesn't seem to be very robust.
>Processes can run on multiple processORS in user mode just fine. But,
>enter the kernel and your SMP is HOZED.
>
>Only one processor (BP) can handle interrupts in SMP too. So if a
>process is in the kernel in another processor, interrupts are not
>handled?
>
>Also, Rubini doesn't say much about threads in the kernel. Maybe
>they're in 2.2.xx ??
>
>He mentions PThread's, but says these are manufactured threads in the
>process and the kernel still sees one process. Therefore if a pthread
>does something in the kernel, the other threads in the process don't
>run.
>
>Don't take this as a flame against Linux or anything. I honestly am
>eager to continue delving into Linux at least as a hobby, and will
>live in whatever environment that entails.
>
>The things I like about NT are:
>
>1) the IRP model. That is, each request from user mode is handed to
>the kernel as an IRP (IO Request Packet). ALL drivers receive IRPs.
>Any driver can generate a new IRP for a lower driver, or pass a
>received IRP onto a lower driver. Therefore a driver doesn't know or
*SNIP*
------------------------------
From: "Alan W. Jurgensen" <[EMAIL PROTECTED]>
Crossposted-To:
gnu.g++.help,gnu.gcc,gnu.gcc.help,gnu.g++.help,comp.os.linux.development.apps
Subject: Now Collect2 linking fails with: multiple definition of ...
Date: Wed, 23 Jun 1999 17:32:25 -0500
Hiya,
Redhat 6.0,
egcs 1.12 (2.91.66)
Im compiling an application that uses some function calls defined in
an archive ../ms/libms.a ...
and some of these i'm override with stub versions of some function calls...
in a local object file rptlib.o ...
Now, compiling and linking fails with: multiple definition of ...
It didnt do this before... Is there some specs or pragma option I need?
How can I get linker to shut up, and just use the module version if finds
first....
help!
thx,
al-man
--
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Alan W. Jurgensen - Full Compass Systems
phone: (608) 831-7330 - email: [EMAIL PROTECTED]
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
------------------------------
From: Rajarshi Bandyopadhyay <[EMAIL PROTECTED]>
Subject: Re: PCI driver blues
Date: Thu, 24 Jun 1999 01:35:58 +0000
Danny Sung wrote:
I
> read... (meaning a 0xffffffff for 32-bit reads)).
>
> I've tried ioremap(), ioremap_nocache() cause it's non-prefetchable
> memory, and __ioremap() with other options I thought might be
> helpful... I've tried ioremap(virt_to_bus(addr)) as well. But
> nothing is getting anything but FF's.
>
Hi all,
I am trying to write a driver for a PCI card too and I am
having a similar problem. Someone pls help .
--Rajarshi
------------------------------
From: [EMAIL PROTECTED] (Arun Sharma)
Subject: Re: NT kernel guy playing with Linux
Reply-To: [EMAIL PROTECTED]
Date: Thu, 24 Jun 1999 01:28:44 GMT
On Wed, 23 Jun 1999 15:48:26 +1000, scottxb <[EMAIL PROTECTED]> wrote:
>
>
> > Rubini says there's a global semaphore that
> > is grabbed every time a process enters the kernel.
>
Careful about the use of the word semaphore. On Linux, semaphore is a
blocking, long term synchronization primitive.
The "thing" used to ensure proper kernel operation on SMP hardware is
a global spinlock.
-Arun
------------------------------
From: XuYifeng <[EMAIL PROTECTED]>
Subject: NR_OPEN & NR_FILE sucks
Date: Thu, 24 Jun 1999 09:53:58 +0800
Hi,
the annoying problem is max opened file descriptors for one
user in Linux is defined by a
CONSTANT --- NR_OPEN, and can not be scaled unless you modify and
recompile kernel,
I want to know why Linux is designed in such silly and suck way?
Redhat has done some hacking job on Linux kernel and let me use shell
command
"ulimit -n ?????" to set very large number of file descriptors, but
this also prevent me from
upgrading to new version of kernel, because I don't know how to hack
kernel :)
does anyone have any idea to modify this limit in Linux kernel?
any help will be appreciated,
XuYifeng
------------------------------
From: Mario Klebsch <Mario [EMAIL PROTECTED]>
Subject: Re: using C++ for linux device drivers
Date: Wed, 23 Jun 1999 21:43:07 +0200
Hi!
Justin Vallon <[EMAIL PROTECTED]> writes:
>These are not C++-ish. There are completely reasonable
>implementations of ::operator new and ::operator delete in terms of
>the C memory allocator. Why do you require anything more complicated?
>If malloc doesn't do a good job, then malloc should be re-written.
Hey, we are in comp.os.linux.development.system!!!
^^^^^^
And we are talking about kernel code. AFAIK, there is no malloc in
the kernel. So you have to do something yourself.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: Michael Gu <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Why we are still holding on to X Windows
Date: Wed, 23 Jun 1999 20:28:08 -0700
This is a multi-part message in MIME format.
==============A5822B086F0CBFD5938D644C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
==============A5822B086F0CBFD5938D644C
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Path:
wnb1!wnmaster1!wn3feed!worldnet.att.net!208.134.241.18!newsfeed.cwix.com!209.208.190.2!news.globix.net!uunet!nyc.uu.net!ffx.uu.net!news.ssi1.com!news
From: Junyang Gu <[EMAIL PROTECTED]>
Newsgroups: comp.os.linux.advocacy
Subject: Why we are still holding on to X Windows
Date: Wed, 23 Jun 1999 13:29:17 -0700
Organization: Silicon Systems, Inc.
Message-ID: <[EMAIL PROTECTED]>
NNTP-Posting-Host: pc721t.tus.ssi1.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
Xref: wnb1 comp.os.linux.advocacy:263983
If Microsoft is a monopoly, X Windows acts more like a monopoly in the
Unix world.
Let's face it. X Windows is a really premitive base for modern GUI,
terrible font support breaks GUI all the time, no sound capability, ....
If Linux is going to desktops to compete with Microsoft, it got to come
up with something much better then X.
So, why don't we drop the X and innovate?
==============A5822B086F0CBFD5938D644C==
------------------------------
From: Martin Maney <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Re: Guides to Linux Performance Tuning???
Date: 24 Jun 1999 02:41:26 GMT
Gopal Santhanam <[EMAIL PROTECTED]> wrote:
> Although my understanding is that VA Research and others offer high
> performance Linux systems with support, I was hoping there might be
> freely available guides on the topic of system tuning for a freely
> available OS. I tried doing some quick searches on performance tuning
> for Linux and found that there is very little documentation on the
> subject. And, the little information I find is rather outdated.
www.nl.linux.org/linuxperf/ - the Linux Performance Tuning Pages
Also of interest, though their work runs more along the lines of research
into optimizing things that are more likely to be configured at kernel build
time or even at coding time:
www.citi.umich.edu/projects/citi-netscape/ - Linux Scalability Project
------------------------------
From: [EMAIL PROTECTED] (John E. Davis)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 24 Jun 1999 03:55:50 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 23 Jun 1999 16:09:29 -0700, Ralph Glebe <[EMAIL PROTECTED]>
wrote:
>I'v started to do some development on the linux platform. Looking at some of
>the source code around, I noticed that it is all C as opposed to C++.
I can tell you why I why I do not use it, although it would be ideally
suited for what I am doing at the moment where I have to resort to
preprocessor macros to fake inheritance from some base class. The
main reasons that I do not use it are that (until very recently) g++
was considered to be very buggy, and I feel that my code is more
portable if I stick to a subset of ANSI C.
--John
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 23 Jun 1999 23:00:33 -0400
[EMAIL PROTECTED] (Terry Murphy) writes:
> In article <[EMAIL PROTECTED]>,
> Emile van bergen <[EMAIL PROTECTED]> wrote:
>
> >Popper (and nature) argue 'piecemeal tinkering' tends to be more
> >efficient than revolutionary design when it comes to adaptivity. Beauty
> >is something else, however, and it seems you're looking for that.
>
> Published studies have concluded that software engineers who follow the
> design->code paradigm are more efficient and productive than those who
> follow the edit->compile->test paradigm, and that the most productive
> software engineers are those who spend the least amount of time in
> front of a computer (and, yes, I can provide bilbiographic citations to
> back this up).
i'm sorry, but i find that statement highly suspicious, and contrary to my
experience with other programmers far better than myself... "lies, damned
lies, and statistics".
in any case,
- who says that the design and code->debug->code proccess can't happen
somewhat in parallel?
- who says that once you code something up, you can't decide that it
sucked and throw all/some away, and start a new design with more
experience behind it?
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.5 i586 | at public servers
That wouldn't be good enough.
-- Larry Wall in <[EMAIL PROTECTED]>
------------------------------
** 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
******************************
