Linux-Development-Sys Digest #302, Volume #6 Mon, 18 Jan 99 22:14:34 EST
Contents:
Re: Upgraded: v2.2.0pre7, glibc-2.0.7pre6 (Johan Kullstam)
Re: Parallel C for Linux (Theo Honohan)
Re: KERNEL 2.0.36 - Unable to open an initial console (James Youngman)
Re: 6 questions on disk files (James Youngman)
Re: 2.2.0pre7 dowsnt load modules (Joe Pfeiffer)
Re: linux vs freebsd (Robert Wuest)
Re: Kernel v2.2 (Edward Lee)
Re: disheartened gnome developer (Christopher B. Browne)
Re: linux vs freebsd (Christopher Browne)
Re: Open Configuration Storage - was Registry for Linux (Christopher Browne)
Re: disheartened gnome developer (Christopher Browne)
Re: Parallel C for Linux (Paul Dietz)
----------------------------------------------------------------------------
Subject: Re: Upgraded: v2.2.0pre7, glibc-2.0.7pre6
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 18 Jan 1999 17:51:16 -0500
Joe Pfeiffer <[EMAIL PROTECTED]> writes:
> Chris Rankin <[EMAIL PROTECTED]> writes:
>
> > Clifford Kite wrote:
> > > I recently installed ppp-2.3.5 with kernel 2.1.131, "make kernel"
> > > copied three files from ppp-2.3.5/linux to /usr/include/net: if_ppp.h,
> > > if_pppvar.h and ppp-comp.h - nothing else. The kernel compiled without
> > > problem using with the ppp.c that came with it.
the real secret is that linux kernel 2.1.131 has a *more recent* ppp.c
file. i don't think you need to do a `make kernel' from ppp. that's
for 2.0.x kernels (since 2.0.x is conservative about adding new
features).
> > Aha! The Secret Formula! I knew there had to be one! (Unless every
> > kernel hacker in the Entire World has a permanent link to the Internet
> > ...) One more point, though: is your primary C compiler for libc.so.5 or
> > for libc.so.6?
>
> My experience with upgrading ppp and 2.0.36 was that ``make kernel''
> was a disaster. While it only copied some of the files over (like you
> say for your later kernel), the result was ppp-related files in
> different places in the kernel which were not compatible. I was able
> to compile 2.0.36 without the ppp upgrade, install the ppp 2.3.5
> programs, and everything seems to be working.
2.0.35 touched something minor in ppp.c. that threw off ppp-2.3.5's
(which hasn't been updated for a while) make kernel script. ppp-2.3.5
looked for timestamps (or versions or something) and compared them to
what it got. ppp-2.3.5 figured you had an up-to-date ppp.c driver.
it was wrong. help out and copy the linux/ppp.c from ppp-2.3.5 into
the kernel driver/net by hand. after this everything should go
smoothly.
hope this helps.
--
Johan Kullstam [[EMAIL PROTECTED]] Don't Fear the Penguin!
------------------------------
From: Theo Honohan <[EMAIL PROTECTED]>
Subject: Re: Parallel C for Linux
Date: 18 Jan 1999 23:59:13 +0000
Vitor Pedro Bonucci Pias <[EMAIL PROTECTED]> writes:
> I have my system running Dual pentium II 450.
>
> The system runing fine with kernel-2.2.0-pre7,
>
> and i would like to know if there is a Parallel C
>
> compiler for Linux to explore the Parallelisme.
Usually, to exploit more than one processor, you need to write your code in
an explicitly threaded style using an API such as POSIX threads. Good
implementations of this API will provide kernel-level threading, so your
threads can run on any available processor in a multiprocessor system. No
magic "parallel C compiler" (small-"p") is required. In the case of Linux,
the implementation you want is linuxthreads,
<URL:http://pauillac.inria.fr/~xleroy/linuxthreads/>
If you are looking for a compiler for some kind of big-"p" "Parallel C",
which will compile normal C programs in such a way that they will
automatically exploit the parallelism of your machine, then you are asking
a lot... You aren't quite out of luck, though; have a look at Cilk,
<URL:http://supertech.lcs.mit.edu/cilk/>, a rather nice multithreaded
language based on ANSI C. It has the extremely neat property that by
eliding all the Cilk keywords in a Cilk program, you get out an ANSI C
program with the same semantics. :-)
------------------------------
From: James Youngman <[EMAIL PROTECTED]>
Subject: Re: KERNEL 2.0.36 - Unable to open an initial console
Date: 17 Jan 1999 22:54:34 +0000
[EMAIL PROTECTED] (Dick Repasky) writes:
> I receive the message from kernel 2.0.36:
> Unable to open an initial console
> just after the kernel mounts the root file system and unmount old
> root. Here are the exact messages:
>
> UMSDOS Beta 0.6 (comptatibility level 0.4, fast msdos)
> VFS: Mounted root (UMSDOS filesystem)
> Trying to unmount old root ... ok
> Unable to open an initial console
>
> The kernel then stops dead.
[...]
> I assume that the error occurs before the kernel reaches for
> /sbin/init. True?
True. From main.c:-
if ((open("/dev/tty1",O_RDWR,0) < 0) &&
(open("/dev/ttyS0",O_RDWR,0) < 0))
printk("Unable to open an initial console.\n");
(void) dup(0);
(void) dup(0);
if (!execute_command) {
execve("/etc/init",argv_init,envp_init);
execve("/bin/init",argv_init,envp_init);
execve("/sbin/init",argv_init,envp_init);
/* if this fails, fall through to original stuff */
pid = kernel_thread(do_rc, "/etc/rc", SIGCHLD);
if (pid>0)
while (pid != wait(&i))
/* nothing */;
}
--
ACTUALLY reachable as @free-lunch.demon.(whitehouse)co.uk:james+usenet
------------------------------
From: James Youngman <[EMAIL PROTECTED]>
Subject: Re: 6 questions on disk files
Date: 17 Jan 1999 22:50:41 +0000
[EMAIL PROTECTED] writes:
> 1) Exactly what policies does Linux employ to keep fragmentation of the
> filesystem to a minimum?
Block groups.
> 2) When data is moved from the disk buffer into RAM through a DMA/ SCSI
> controller, how many times is it moved from one buffer to the next before it
> finally finds its way into user-space?
I don't know.
> 3) I'd like "allocate contiguous uninitialized space" on disk. That is, I
> want to create a few very large (a few hundred MB) files and "fill" them with
> data at a later time.
I don't think the kernel provides for this. If files don't do this
fast enough for you, try writing on blank partitions. Otherwise, go
for RAID.
> 4) Suppose I'm employing a SCSI disk/disk controller, and I want to access
> four small chunks of data, A, B, C and D, on the same track, and I've made my
> requests in that order, A, B, C and D. Suppose, however, that the chunks lie
> on the track in REVERSE order, first D, then C, then B, then A. Does the
> device driver or the controller manage to collect them in just one
> revolution, or does it need four (actually from three and a little bit to
> four)? Does the answer change with an UDMA disk/disk controller?
(in general) Pass. Yes.
> 5) Again, in the two situations of SCSI and UDMA, suppose I want to read a
> large sequential file and update it with new data. Assume the data are
> already available before the read phase begins. Is it possible to have the
> disk read the contents of a track, then IMMEDIATELY update that track before
> moving the head to the next one? This would spare one out of two head
> movements, compared to the case of, say, reading the file completely and then
> starting over and overwriting it.
As far as I know, no disks will write to and read from a sector at the
same time. Hence, if a sector must be read *and* written, I assume an
extra disk rotation is required, unless the data is kept in the disk's
write cache instead (or unless the data to be read was in the cache,
and so only the write was in fact required).
> 6) Is it possible to create a file which corresponds exactly to one physical
> track (i.e. is contained in a single track and comprises all blocks of that
> track)?
No. Modern IDE disks for example will usually not even tell you what
their "true" physical geometry is.
--
ACTUALLY reachable as @free-lunch.demon.(whitehouse)co.uk:james+usenet
------------------------------
From: Joe Pfeiffer <[EMAIL PROTECTED]>
Subject: Re: 2.2.0pre7 dowsnt load modules
Date: 18 Jan 1999 12:21:37 -0700
I also was unable to load modules in 2.2.0pre7. In my case, ``depmod
-a'' printed no messages at all, and cleared my
/lib/modules/2.2.0-pre7/modules.dep file. Various combinations of
options to depmod (-e, -s, -v) made no difference at all; running it
on a particular module would give a long list of unresolved symbols.
This was with modutils 2.1.121 (kernel and modutils compiled from
sources with egcs-1.1.1). At the moment I'm back at 2.0.36 and
modutils 2.0.0...
Haven't tried upgrading klogd yet... which of the packages in
Documentation/Changes contains it?
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
------------------------------
From: Robert Wuest <[EMAIL PROTECTED]>
Subject: Re: linux vs freebsd
Date: Mon, 18 Jan 1999 18:44:02 +0000
Nathan Myers wrote:
>
[SNIP]
> (Except, beginners should stay away from Slackware.)
Unless they really want to learn Linux inside out. It may be argued
that one can learn Linux on any of the distros, but after successfully
installing Slackware, you're gonna know Linux.
Robert
------------------------------
From: Edward Lee <[EMAIL PROTECTED]>
Subject: Re: Kernel v2.2
Date: Wed, 06 Jan 1999 08:37:32 -0800
Thank you, i did not know about the name change and i did not look hard
enough.
I found it at
ftp:ftp.cdrom.com/pub/linux/tsx-11/kernels/v2.1/modutils-2.1.13.src.tar.gz
I hope this will help several other people having the same problem.
Theo Honohan wrote:
> Edward Lee <[EMAIL PROTECTED]> writes:
> >
> > Nop, modutils is not the right stuff.
> > Modules-X.X.X is a stealth package.
> > It is still hidden somewhere out there.
> > I am wondering why it is not included in the kernel sources.
> > Without it, i can't build any modules at all.
>
> This is wonderfully poetic. However, the programs once distributed in
> modules-2.0.0 come in a package called modutils now. It really *is*
> what you need.
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Reply-To: [EMAIL PROTECTED]
Date: Tue, 19 Jan 1999 01:21:14 GMT
On Mon, 18 Jan 1999 15:39:04 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> posted:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> Red Hat "dropped" some Python/Tk configuration tools, in favor of
>> supporting Linuxconf; that happened with barely a whimper, as nobody
>> really cared very much, or was terribly inconvenienced by the "loss."
>> I have a hard time caring, myself. There are better things to expend
>> emotional energy on.
>
>Sure. But that's not dropping, it's replacing.
>We were discussing things like "Red Hat goes propietary". In that case,
>you don't get linuxconf, you get the old Python/Tk tools and no maintainer.
At which point people take the Linuxconf sources, which are available from
the original producers that *aren't* at Red Hat, or, for that matter, from
the same *country* as RHS, turn their backs on Red Hat Software, and
continue from there.
Linuxconf doesn't use the GPL, but rather a license that fits on a single
page and strongly resembles the GPL...
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to Linux today?..."
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: linux vs freebsd
Reply-To: [EMAIL PROTECTED]
Date: Tue, 19 Jan 1999 02:16:30 GMT
On Mon, 18 Jan 1999 18:44:02 +0000, Robert Wuest <[EMAIL PROTECTED]>
wrote:
>Nathan Myers wrote:
>>
>[SNIP]
>> (Except, beginners should stay away from Slackware.)
>
>Unless they really want to learn Linux inside out. It may be argued
>that one can learn Linux on any of the distros, but after successfully
>installing Slackware, you're gonna know Linux.
Slackware encourages the use of "test to failure."
If you install Slackware, and go through the process of upgrading from
libc5 to libc6 by hand, and other upgrades of similar scope, you'll have
put yourself through an "obstacle course" that is highly instructive.
You'll learn a lot.
Part of the point is to "do stuff" until the system breaks, and then
figure out how to fix those problems.
Much of that effort isn't as necessary with the more 'modern'
distributions, as they have collected together a lot of package
configuration information that allows their package management systems
to, to a much greater extent, clean up messes for you, and to just plain
put files in the right spots.
Unfortunately, all of those approaches involve introducing yourself to a
great deal of frustration, and will involve not having a system that you
can feel you can rely on.
Both of which are things that, to a great extent, people are looking to
Linux to help them avoid, after great frustrations on other platforms.
--
"Bother," said Pooh, "Eeyore, ready two photon torpedoes and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Open Configuration Storage - was Registry for Linux
Reply-To: [EMAIL PROTECTED]
Date: Tue, 19 Jan 1999 02:16:24 GMT
On Sat, 16 Jan 1999 09:10:12 GMT, George MacDonald <[EMAIL PROTECTED]> wrote:
>Christopher Browne wrote:
>I'm not familier with MSMQ/TIB/OM3. What do they give you over
>normal sockets?
They give you rather fuller transaction handling; it should take a
really catastrophic situation, worse than merely power-off, to lose
transactional data.
>> In the above bit, I've assuming having some hi-tech stuff like CORBA and
>> message queueing; the issues should still hold true if we're talking
>> about having some processes talking through sockets with less
>> sophistication involved.
>
>Actually CORBA would limit your ability to pick the connection style,
>hence will increase your connection times for a single request.
>Well I should say IIOP, other ORB protocols could be implemented.
That's fair.
>The real problem is that useful knowledge about efficiency lives
>a layers above the level where it can be used.
Unfortunately so.
>> Overall points:
>>
>> 1- Despite some adverse comments above, message queueing at some level is
>> probably a useful idea.
>>
>Are these "messages" persistent across system reboots?
I suppose that will have to depend on what is wanted.
In transaction processing systems, messages are intended to be
effectively persistent *forever.*
Issuance of a cheque might be a message; once that transaction has been
committed, it's a done thing. Which has nothing to do with boots,
reboots, or even moving the general ledger to a different server.
On the other hand, there may be things in system configuration that go
away at the end of a "session;" whether they should be reset at bootup
or not is a good question.
>I have started discussions with the GNU team(Richard Stallman) regarding
>the project. He has an interest in doing an "application configuration"
>project for GNU. His focus is a little different than what we have been
>discussing but there is also much in common. I'll keep you posted regarding
>it's progress.
Based on recent stuff on the Debian/Hurd list, there's a need to have
applications not need to be *too* discriminating as to where they're
installed. (One of the ideas of Hurd is to effectively have things like
$PATH be something that is provided to you transparently through a
"shadow filesystem;" this is likely to make /usr go away, which is the
immediate problem...)
Interesting times, to be sure...
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning."
-- Rich Cook
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/tpmonitor.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Reply-To: [EMAIL PROTECTED]
Date: Tue, 19 Jan 1999 02:16:33 GMT
On Mon, 18 Jan 1999 15:39:04 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> On Fri, 15 Jan 1999 16:55:09 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>> posted:
>> >In article <77h02o$bg6$[EMAIL PROTECTED]>,
>> > [EMAIL PROTECTED] wrote:
>> >> On Sat, 09 Jan 1999 14:48:45 GMT, [EMAIL PROTECTED]
>> >> <[EMAIL PROTECTED]> wrote:
>> >> >Red Hat does own the code they create, just like Troll Tech and Microsoft.
>> >> >That you have a copy of it under the GPL doesn't mean they can't later
>> >> >re-release it under a proprietary license.
>> >>
>> >> Technically, that's true.
>> >>
>> >> Unfortunately for such a release, they cannot "de-release" the software
>> >> already released under the GPL, which means that the software that they
>> >> have written will continue to be freely available (barring *bizarre*
>> >> events) and could be maintained, moving forward by others.
>> >
>> >Sure. Technically :-)
>> >Then again, usually when a program with a low "cool factor" like, say,
>> >a Tk front end to network configuration gets fropped it often just stays
>> >dropped. Even high profile projects like the GIMP had a rough season
>> >after the original maintainers dropped it (things a re better now,
>thankfully)
>>
>> Indeed. If nobody cares about the software, if some "catastrophe" strikes,
>> no one will notice.
>
>It is very possible that many people care and notice, and still they can't
>take it over. Like in the GIMP example. People who use it are mostly not
>programmers.
If they care a whole lot, they can hire a programmer to fix/update the
software. There may be substantial cost to that, but it is at least:
a) Permissible, and
b) Does not require obtaining a license from a third party.
>> Red Hat "dropped" some Python/Tk configuration tools, in favor of
>> supporting Linuxconf; that happened with barely a whimper, as nobody
>> really cared very much, or was terribly inconvenienced by the "loss."
>> I have a hard time caring, myself. There are better things to expend
>> emotional energy on.
>
>Sure. But that's not dropping, it's replacing.
>We were discussing things like "Red Hat goes propietary". In that case,
>you don't get linuxconf, you get the old Python/Tk tools and no maintainer.
I wasn't aware that Linuxconf was a proprietary product of Red Hat
Software any more than the former Tk/Python tools were. The last time I
visited the Linuxconf web site, the main developers weren't even in the
same *country* as Red Hat Software.
I don't have license handy, but I thought that Linuxconf was also either
GPLed or LGPLed, thus meaning that if Red Hat "goes proprietary,"
Linuxconf is something that you *do* "get." If I'm wrong, feel free to
quote from the license.
>> >> Troll Tech has a legal arrangement whereby if "disaster strikes," a
>> >> scenario similar to the above is invoked. Red Hat has already invoked
>> >> the "disaster clause."
>> >
>> >Not exactly, since the result of that "disaster clause" is not the
>> >release under the GPL of the software in Troll tech's case.
>>
>> A *precise* parallel? No.
>>
>> Relatively similar? I'd think so. The GPL and BSDL have different
>> sorts of restrictiveness; both are commonly regarded as representing
>> "free" software. Albeit with some noisy dissenters.
>
>The GPL is "free with strings attached" BSDL is free.
>Some people don't care about the strings, some people like the strings, but
>there are strings :-)
BSDL has a different set of strings. If we're talking about the
"formal" BSDL, there is a requirement of authorship disclosure that is a
string. RMS has flamed the BSDL for this reason.
And there's the "string" that someone can take BSDL code and produce
entirely proprietary results, which some people apparently object to.
<tone tongue="in cheek"> That "free" code can be captured and "enslaved"
by evil corporate folk to horrible proprietary purpose... </tone>
And there are those that dissent in both directions, as I said.
--
"Bother," said Pooh, "Eeyore, ready two photon torpedoes and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: Paul Dietz <[EMAIL PROTECTED]>
Subject: Re: Parallel C for Linux
Date: Tue, 19 Jan 1999 02:37:59 +0000
Theo Honohan wrote:
> cally exploit the parallelism of your machine, then you are asking
> a lot... You aren't quite out of luck, though; have a look at Cilk,
> <URL:http://supertech.lcs.mit.edu/cilk/>, a rather nice multithreaded
> language based on ANSI C. It has the extremely neat property that by
> eliding all the Cilk keywords in a Cilk program, you get out an ANSI C
> program with the same semantics. :-)
I second this vote for Cilk. It's a nice language based
on a theoretically nifty scheduling technique. Very efficient.
It would be a real feather in linux's cap if many linux
application programs could effectively use SMP machines --
especially if chip-level multiprocessing (putting several
CPU cores onto a single chip, sharing an on-chip cache)
becomes popular, as some are predicting. (Go to
http://www.chipanalyst.com/q/ and look at the 12/28/98
editorial.)
Paul
------------------------------
** 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
******************************
