Linux-Development-Sys Digest #218, Volume #6 Tue, 5 Jan 99 06:14:22 EST
Contents:
Re: What does "set_fs( )" and "get_fs( )" ? (H. Peter Anvin)
Re: GUI, The Next Generation (Peter Samuelson)
Registry for Linux - Why? ([EMAIL PROTECTED])
Re: Kernel-2.2-pre2 (Peter Samuelson)
Re: Registry for Linux - Bad idea (Tristan Wibberley)
2.2.0pre1 and GDB-4.17, linux/debugreg.h no longer? (Doug McClendon)
Re: 2 stacks? (Peter Samuelson)
Re: VB Converter? (Talon Karrde)
Re: Registry for Linux - Bad idea (Christopher Browne)
Re: Kernel v2.2 (Talon Karrde)
Re: Registry - Already easily doable, in part. (Andrew Morton)
Re: Help with kernel error message... ("D. Stimits")
Kernel2.2 Questions (Micha)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: What does "set_fs( )" and "get_fs( )" ?
Date: 5 Jan 1999 07:13:38 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <76qgar$95r$[EMAIL PROTECTED]>
By author: "J. A" <[EMAIL PROTECTED]>
In newsgroup: comp.os.linux.development.system
>
> I'm wondering if anyone can tell me what the functions "set_fs()" and
> "get_fs( )" does?
>
> I am using these functions in a little "device driver" I'm working on, and
> they makes it possible to read and write to/from a file on disk. Without
> them it doesn't work. So if you know what these functions actually do,
> please let me know!
>
You can use them to make functions that normally access user space
pointers (like write) to access kernel space instead.
The function names date back from the earliest days of Linux
(pre-portability) when, inside the kernel, the %ds and %es segment
registers pointed at kernel space and %fs pointed at user space.
By loading the proper value into %fs, you made it access kernel space
instead.
Those early versions of Linux used i386 segment limit checking to
enforce the user space barrier; nowadays it uses page-level protection
and explicit pointer checking, for portability.
-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] (Peter Samuelson)
Subject: Re: GUI, The Next Generation
Date: 5 Jan 1999 01:57:49 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Derek B. Noonburg <[EMAIL PROTECTED]>]
> Or how about this: holding down that useless left-windows key (on new
> "Win95 keyboards") would instantly turn all windows translucent.
Hey, you messing with my meta key? (Recall that X11 allows for
separate meta and alt keys. I'm not sure who originally thought the
world needed both, but thanks to the "useless key", XFree86 lets you
have them.)
Your idea *does* have merit, though. The colormaps would be a
nightmare to maintain, but maybe future graphics cards could help out
with some sort of hardware-managed layers with alpha channels. The
GIMP on a graphics board, as it were.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED]
Subject: Registry for Linux - Why?
Date: Tue, 29 Dec 1998 22:43:25 GMT
There have been people who have asked for a "Windows Registry" - like
configuration database for Linux.
Why do you want it, and what do you want exactly?
What are your arguments for a "Registry"-like database?
I am not interested in peoples arguments against a registry. I agree with you.
It sucks. But everything has good points, and I want to know what they are.
Then, we could try to find ways to work those things into Linux.
AND I AM STILL NOT SAYING THAT I WANT ANY REGISTRY! So don't flame me
or discard this post just because it contains the word "Windows", please.
I am also interested in the various ways applications access information in
config files. I have noticed two models, but there may be more.
1. Query the config when information is needed.
2. Go through each entry in the config file and apply each setting.
3. Combinations of (1) and (2).
Thanks beforehand.
--
/ jjoohhaann@@ttiiqq..ccoomm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Kernel-2.2-pre2
Date: 5 Jan 1999 01:40:23 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[D. Stimits <[EMAIL PROTECTED]>]
> I haven't compiled the 2.2.0pre version, but I assume to enable or
> disable the SMP you still have to uncomment/comment out the Makefile
> SMP=1 line. If the config scripts are doing it right, you could still
> manually do this in Makefile.
Nope. Linus finally merged in mec's CONFIG_SMP patch in 2.1.131 or so.
So now SMP is a `make *config' option. (Thanks, Michael, thanks,
Linus. (Now if only devfs could have made it into 2.2....))
As I understand it, the reason it wasn't before is that back before the
`make dep' wizardry, every file that used any CONFIG_* option -- and
thus had to #include <linux/config.h> -- would be recompiled every time
a config option was changed. With a CONFIG_SMP, this would mean nearly
every file in the whole kernel. Meaning, everything gets recompiled
when you change the IRQ for your Sound Blaster. This problem was
minimized by many files not needing `config.h' at all.
The new mkdep.c/split-include.c code fixed everything by increasing the
dependency granularity to a single CONFIG_* option, rather than the
whole <linux/config.h> file. mec and Werner Almesberger, who thought
of this scheme (and its implementation as a directory tree), are
geniuses.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Tue, 05 Jan 1999 02:12:22 +0000
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
>
> In article <76r0va$tnq$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Craig Kelley) wrote:
>
> >
> > And yet nobody has been able to come up with anything better.
>
> Because everyone is too busy bashing the alternatives rather than trying to
> create one.
>
> >
> > It is *not* dated, unscalable nor unwieldy. Using tools such as
> > secure shell or rdist one can easily write a program to update
> > numerous machines automatically. It took me less than an hour to come
> > up with a perl script which updates all of our Linux servers
> > automatically. It does this using RSA encryption, and requires each
> > machine's root password to be typed in before it will execute. The
> > reason why these things are so easy to construct: they use PLAIN OLD
> > TEXT and standard I/O.
>
> You, are a system administrator. You know perl, you're familiar with rdist,
> sounds to me like you used PGP to encrypt outbound data. Clearly, you have a
> command over the systems involved here.
>
> Not everyone does.
Do you intend this registry to be something for the average end user
granny to be able to edit directly? I don't think it will be any easier,
actually I think it would be harder. A format for each task is much more
intuitive - your format can match the data so the person configuring
won't have to think. Maybe the current formats would be better, but
choosing one format for all is IMHO the wrong way to go. But of course,
you are free to prove me wrong by implementing the new scheme and
getting a granny to tell you which is easier.
> >
> > As for it being expensive for "administration and training resources",
> > I have one word: linuxconf. I think you will be very surprised when
> > RedHat 6+Gnome+linuxconf hits the shelves.
>
> I cant wait. I hope it becomes the standard adminsitration tool. I hope it
> fits on the rescue floppy too.
If you need a rescue floppy, linuxconf won't help you - a text editor
will though. Even flat text becomes hard to parse in severe cases.
> >
> > Linuxconf already works just fine, and it has managed to centralize
> > more configuration information in one easy-to-use place than Microsoft
> > has ever dreamed of (SMC is just a ghost of what linuxconf can already
> > do).
>
> It's my understanding that linuxconf works by directly accessing the text
> files when it needs to do work. Wouldn't it be nice if linuxconf only had one
> interface into all the configs?
It would be nice for the programmers of linuxconf, but that's all. You
only end up forcing that interface on the application programmers
though. If you dont force it on them, they'll keep to their own format
which linuxconf will need a module for.
Here is what I propose to be a fact - feel free to explain why I'm wrong
(I would like to be, but I don't think I am):
There will never be a single configuration format.
This is because the people who maintain current software don't wan't to
change it to what you want (they are die hards who wan't to KISS).
With this fact in mind, you will never have one programatical interface
and one general tool. So this is not a reason for what you propose.
Agree?
> Wouldn't it be nice if someone who is using
> vi or emacs on a config file would not clobber changes that are pending in
> linuxconf?
Why? if the admin wants to do it let them - if your using linuxconf, you
either won't care to touch the config manually or you know how to avoid
clobbering.
> Wouldn't it be nice if the folks at RedHat could concentrate on
> making the interface truly first rate rather than coding plugins and allowing
> for software changes everytime the author of a program gets industrious?
It would be lovely, but whichever system you choose, this will have to
be done. If a peice of software changes, the linuxconf module must be
altered (by the way, no smart programmer will rewrite a whole format
without it being absolutely necessary).
So are you suggesting that once linuxconf gets written, all software
that it can configure may not change (eg add new keys/remove them?) as
they would even under your propsed scheme?
=========================
The only credible argument I've seen for a change is the network wide
admin - and I'm not convinced that flat text files still can't do the
job but with a network protocol for accessing them.
For this argument:
There are typically four locations for configuration files:
/etc
/usr/etc
/usr/local/etc
${HOME}
/usr/etc can be network mounted, /usr/local/etc can be network mounted,
${HOME} can be network mounted.
most of the stuff in /etc (at least with debian) is stuff which should
not be network mounted (hardware and network connection details), or is
configurable in scripts so it can be network mounted too.
This gives you the network configuration, stick in a server on the local
machine so the config server can announce an update, and the server gets
the system to update and restart relevent portions.
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: Doug McClendon <[EMAIL PROTECTED]>
Subject: 2.2.0pre1 and GDB-4.17, linux/debugreg.h no longer?
Date: Tue, 05 Jan 1999 03:26:51 GMT
While trying to rebuild gdb-4.17 on my 2.2.0pre1 system,
it complained about the lack of /usr/include/linux/debugreg.h
which does exist in 2.0.36. However now it looks like the
only place this file exists is in /usr/src/linux/asm. I imagine
that if I edit various makefiles I can get it to build, but I just
figured I'd mention it since probably there was a reason it used
to be there, or a reason it's not. Either gdb or linux needs to be
changed.
-dmc
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: 2 stacks?
Date: 5 Jan 1999 02:19:10 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Stephen Lee]
> How about making the stack grow forward instead of backward, that way
> you can only overflow into unused stack memory rather than the return
> address...
Not a bad idea, but it would sort of require redesigning your CPU.
Can't do it in software. (No, that *isn't* what `std' and `cld' mean
on the i386!)
For what it's worth, I do not know why most CPUs grow stacks downward.
I remember idly wondering about it way back while learning 6502, but I
think I wrote it off at the time -- it was no more counterintuitive
than, say, being little-endian.... Besides, I thought, the 6502 is
legendary for its quirks.
Hmmm, that brings up a point -- if MIPSen and Merceds can change
endianness on the fly, can they also change stack direction?
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Talon Karrde <[EMAIL PROTECTED]>
Subject: Re: VB Converter?
Date: Mon, 04 Jan 1999 20:11:33 -0800
Stephen wrote:
> Is there a Visual basic converter around to convert VB GUI's to X GUI's? If
> there isn't, it would be a kewl project eh?
Stephen: Try "Visual TCL". It isn't a converter, but it is a GUI development
tool similar to VB, and it can make cross-platform apps. No URL handy, but your
distribution should have a copy of it.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 5 Jan 1999 02:48:08 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 04 Jan 1999 21:37:52 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>In article <76r0va$tnq$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Craig Kelley) wrote:
>
>> And yet nobody has been able to come up with anything better.
>
>Because everyone is too busy bashing the alternatives rather than
>trying to create one.
>
>> It is *not* dated, unscalable nor unwieldy. Using tools such as
>> secure shell or rdist one can easily write a program to update
>> numerous machines automatically. It took me less than an hour to come
>> up with a perl script which updates all of our Linux servers
>> automatically. It does this using RSA encryption, and requires each
>> machine's root password to be typed in before it will execute. The
>> reason why these things are so easy to construct: they use PLAIN OLD
>> TEXT and standard I/O.
>
>You, are a system administrator. You know perl, you're familiar with rdist,
>sounds to me like you used PGP to encrypt outbound data. Clearly, you have a
>command over the systems involved here.
>
>Not everyone does.
Evidently so...
>> As for it being expensive for "administration and training resources",
>> I have one word: linuxconf. I think you will be very surprised when
>> RedHat 6+Gnome+linuxconf hits the shelves.
>
>I cant wait. I hope it becomes the standard adminsitration tool. I hope it
>fits on the rescue floppy too.
Linuxconf is liable to be a bit too big for the rescue floppy; the more
it does, the more space it will consume. So long as it stays pretty
modular, it should be possible to omit bits that are less critical to
rescuing a system; solution might lie there...
>> Linuxconf already works just fine, and it has managed to centralize
>> more configuration information in one easy-to-use place than Microsoft
>> has ever dreamed of (SMC is just a ghost of what linuxconf can already
>> do).
>
>It's my understanding that linuxconf works by directly accessing the text
>files when it needs to do work. Wouldn't it be nice if linuxconf only had one
>interface into all the configs? Wouldn't it be nice if someone who is using
>vi or emacs on a config file would not clobber changes that are pending in
>linuxconf? Wouldn't it be nice if the folks at RedHat could concentrate on
>making the interface truly first rate rather than coding plugins and allowing
>for software changes everytime the author of a program gets industrious?
It might be nice to only need one interface into all configs; that's
*NOT* likely to happen tomorrow or the next day.
It would, nonetheless, be a worthwhile thing if instead of needing
parsers for (say) 80 data file formats, "libconfig" could cut this down
by a dozen.
That would probably be worthwhile enough to convince people to look at
modifying another dozen system services to be controlled via
"libconfig-compatible" configuration. There might still be 30
facilities in the end that would *never* use "libconfig." It would still
be better to have "libconfig" than not.
A pretty appropriate comparison to draw is with regard to the various
"option parsing" libraries. There are a number of them available, of
varying degrees of sophistication.
It's easy enough, in C, to fiddle with argc/argv, that people often
enough "roll their own" argument parsers. If people made more common
use of one or two of the better argument parsers, this could improve the
consistency of the parsing of commands. Fortunately, since Microsoft
really only does GUIs, there are few Windows comparisons to be drawn,
and thus little availability of controversy with regard to option
parsing.
--
The nice thing about Windows is - It does not just crash, it displays a
dialog box and lets you press 'OK' first. (Arno Schaefer's .sig)
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: Talon Karrde <[EMAIL PROTECTED]>
Subject: Re: Kernel v2.2
Date: Mon, 04 Jan 1999 20:17:06 -0800
> Where did you get the modules package to compile 2.1.132?Did you find a newer
> modules package in debian somewhere?
> I need the "-k" option of genksyms in the modules package.
> With modules-2.0.0 (in sunsite & tst-11 mirrors), i can't even compile the
> kernel.
Go to http://www.kernel.org/ (or is it kernels.org, try both :-) and get the
2.1.132 tgz file. Kernel.org is the master distribution point (i think), the
source there compiles fine on Debian 2.0 (hamm), and I'm using a frozen release!
I don't know about the modules package, but it should be available there too.
------------------------------
From: Andrew Morton <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: Tue, 05 Jan 1999 21:52:43 +1100
Todd Knarr wrote:
>
> In comp.os.linux.development.system Andrew Morton <[EMAIL PROTECTED]> wrote:
> > 1: They're Linux specific.
>
> No, they're specific to the class of systems that have a filesystem
> with a namespace conforming roughly to Unix conventions ( 255 characters,
> extensions not special, optionally case-sensitive ).
I was referring to the proposals which would require kernel
modifications: magical /proc files, files which are in reality attached
to processes, etc.
> > 2: They're "single system centric" (tm). We need to pay more
> > recognition to the requirement that reconfiguration of applications is
> > an enterprise-wide function. The rdist approach is klunky (how do I
> > simply change/propagate a single line of config?)
>
> For single-line changes, you rdist the appropriate sed script and apply
> it.
What I'm getting at is that a one-line change implies all config is to
be rescanned. This edit/SIGHUP scheme works now because application
developers have never had anything else available.
One should, for example, be able to add/delete/modify a line to
/etc/inetd.conf and not have to whack inetd. This is a trivial case.
If a mechanism existed for applications to be notified of
reconfiguration, they would have used it extensively and ave been more
sophisticated as a result.
[ You should see the crap I have to go through to be able to PPP into
either uow.edu.au _or_ Nortel's intranet - sedding /etc/resolv.conf,
massaging named.boot, restarting named. It stinks. ]
> For machines with truly common configurations there exists this
> thing called a network file system, although as with any non-local config
> source you have the problem that, when the network is down and the
> non-local config source cannot be reached, everything on the network
> stops dead ( which is _not_ graceful degradation of service by any
> definition ). And I have seen very few systems in reality that have a
> single enterprise-wide configuration. More often you have multiple
> configurations which need applied to multiple sets of machines, with
> noticeable overlap between configurations and sets of machines but not
> enough to actually combine either.
>
> Part of the problem is that I work in an environment where all of the
> machines I normally deal with are either several steps ahead of the
> rest of the company ( developing the software that will be rolled out
> in 6-12 months ) or several steps behind the rest of the company ( the
> configuration and versions being determined by what critical software
> needs to have to run rather than what the latest version is ).
>
> > 3: They do not provide for notifications to running applications.
>
> This is a good thing. As noted a while back, it is very common to make
> several changes in several steps and test them on one machine before
> committing all machines to using them. This is usually best handled by
> having the applications only re-read config data when told to. Automatic
> detection or notification has a nasty tendency to re-read the data when
> you have almost but not quite finished with all the changes, leaving the
> application in a state which is almost but not quite entirely unlike any
> it ought to be in.
I agree. As George points out, nodes further down the hierarchy need to
be able to apply local overrides to data from higher up. And
commit/rollback functionality is needed so that clients see the updates
atomically.
------------------------------
Date: Mon, 04 Jan 1999 21:21:30 -0700
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Help with kernel error message...
"Brian C. Thomas" wrote:
>
> Hi all,
>
> I am running 2.2.0-pre4. In my syslog file, I am getting this error
> intermittantly, but persistantly...
>
> darkstar kernel: Symbol table has incorrect version number
>
> Can anyone explain this to me, and perhaps a way to get it fixed?
>
> Thanks,
>
> bct
I haven't run the 2.2.0x, but it looks like you left old modules in /lib/modules/2.x.x
directory.
Try moving them to a backup subdir like /lib/modules/2.x.x_old/ (like with cp -adpr),
then
re-running "make modules" and "make modules_install". I you happened to recompile all
of your old
modules it'd overwrite them and not complain, but if you changed what modules you use,
it'd leave
something behind. It isn't guaranteed to be the particular symbol table, maybe it is a
libc symbol
table...but it is a good and free test to recompile modules.
------------------------------
From: Micha <[EMAIL PROTECTED]>
Subject: Kernel2.2 Questions
Date: Tue, 05 Jan 1999 10:51:29 +0100
Hi all !
Does anybody know why the Kernel2.2-pre[1,4] reports
"unable to find map file" at startup ?
My System.map is in the / directory ( that was the right
position for the 2.0 kernels).
Further I encounter some problems using lsof since I use
the new kernel.
It reports "to many maps" ( or something that way ).
Thanx in advance,
schulzmi.
============================================================
Michael Schulze
University of applied sciences - Brandenburg
http://zeus.fh-brandenburg.de/~schulzmi
email:[EMAIL PROTECTED]
============================================================
"...when your girlfriend's got a penis something's wrong..."
K's Choice
------------------------------
** 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
******************************
