Linux-Development-Sys Digest #219, Volume #6 Tue, 5 Jan 99 09:16:24 EST
Contents:
Re: What does "set_fs( )" and "get_fs( )" ? (Kenneth Crudup)
Re: Registry for Linux - Bad idea (Andrew Morton)
Re: Registry for Linux -> Use CORBA!!! (George MacDonald)
Re: Registry for Linux - Bad idea (George MacDonald)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Kenneth Crudup)
Subject: Re: What does "set_fs( )" and "get_fs( )" ?
Date: 5 Jan 1999 07:26:32 -0500
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says:
>["strace"] outputs system calls in a C-like syntax.
But won't help him in the kernel.
The quick, non-authorative answer: "get/set_fs()" are routines for use in the
kernel to load the "FS" register, which is commonly used as the destination
(source? I forget) selector for a number of i386+ assembly op-codes. Most
likely (I don't have my Rubini nearby) it's used as an assembly-language
(#asm) hook to access user-space.
-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: Andrew Morton <[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 23:27:03 +1100
Craig Kelley wrote:
>
> In article <[EMAIL PROTECTED]>,
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> ->The Unix model of:
> ->
> ->- Every app has its own config file
> ->- Every app has its own code to read that file
> ->- Every app needs a restart when something changes (or SIGHUP: almost
> ->the same thing)
> ->- Config is local to this host
> ->
> ->is _extremely_ dated, unwieldy, unscalable and expensive. It's
> ->unreliable and requires excessive administration and training resources.
>
> And yet nobody has been able to come up with anything better.
IYHO, Craig.
> 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.
- no provision for local overrides (inheritance)
- apps must be restarted
- requires clients to be online
- all the other things we've been saying.
> 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.
Linuxconf is an attempt to graft a uniform interface onto legacy chaos.
What we're doing here is exploring the requirements and design of a
_new_ approach which will be uniform from end-to-end. Please stop
shouting at us - some good may come of all this.
A few random thoughts:
- As one of our Microsoft friends pointed out in the halloween docs, the
OSS community is good at following tail lights. We are now almost in
the embarrassing position of being in the overtaking lane. It's time to
look ahead and to innovate. This will require some evolution of the
communication and management model.
- The discussion here tends to leap ahead of itself: we're getting into
fine grain implementation issues without having identified the
requirements. Can we please take this from the top? George's page at
http://24.1.97.22/gmd/opStore/index.html seems a good starting point.
I'd like it to have an explicit 'requirements' section.
- ACAP http://www.ietf.org/html.charters/acap-charter.html has
everything I want (I think) but it is heavyweight, in the sense that it
is unsuitable for configuring many of the /etc/*.conf things.
This problem can be resolved with a periodically invoked (or daemon)
ACAP client which rebuilds /etc/*.conf based on the ACAP server and does
all the necessary signalling. [ This requires that named, apache, etc
can all seamlessly hold their current transactional state across a
SIGHUP. This I doubt. ]
- Anyone know how to plug into the anonymous IMAP server? "Archive:
anonymous IMAP: cyrus.andrew.cmu.edu:archive.ietf-acap " - Netscape
won't let me configure an IMAP server alongside POP :-(
- The gnome-list / [EMAIL PROTECTED] folk have pointed out that XML is
an appropriate data representation.
- George: any ACAP opinions?
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux -> Use CORBA!!!
Date: Tue, 05 Jan 1999 03:50:11 GMT
Andrew Morton wrote:
>
> George MacDonald wrote:
> >
> > [ deletia ]
> >
> > The architecture I am thinking about is as follows:
> >
> > ---------------------------------------------
> >
> > Applications
> >
> > Library CORBA File System SNMP
> > Interface Interface Interface Interface
> > | | | |
> > | | | |
> >
> >
> > Configuration Services
> >
> > | | |
> > | | |
> > Flat files Relational DB OO-DBMS
> >
> > --------------------------------------------------
> >
>
> George, I believe CORBA should be in there from day one. Gnome's ORBit
> seems lightning fast - I'd like so see it benchmarked against
> open()/parse()/close() of a config file.
>
I'm not so concerned about processing speed as I am about wider
deployment and scaling costs with functionality with requrements.
> Make the architecture:
>
> Client app:
> API
> |
> ORB
> |
> Local config server: |
> ORB
> /|\
> / | \
> / | \
> / | \
> / | \
> flat DBMS Remote management entity ORB
> files
>
> The top-level API would hide the CORBA/file/DBMS/remote manager
> details. The ORB's there for apps which need higher functionality such
> as notifications, config writeback, etc.
>
> BTW: A lot of what you're proposing seems to be in KDE: system-wide
> hierarchical config with per-user overrides, the ability to write back,
> etc. Looked at it?
Not yet. Your ideas are very close to what I was thinking about.
My reason for starting with flat files and a library are that
it's simple and doesn't require ORB knowledge for developers.
There are many people who still program in C and probably
will be for a long time. Having learned the OO methodology
I am converted, but I recall how much effort it takes to
aquire the knowledge. I want to provide a simple interface
for simple programs, thus enabling all programmers.
Yeah I know, we could hide it all behind the library, but
it still requires the CORBA software to be downloaded,
installed ... Then if something breaks the developers
have to figure out CORBA just to do a simple config
change!
I know of both GNOME and KDE but still don't have them
running on my system, that should give you some idea
of why I don't want to be bound to an ORB/CORBA. I
do however want to use that as a mechanism when an
app is CORBA based. I also think it reasonable to limit
the functionality of a flat file/library implementation.
So what you describe is a subset of what I am thinking
about. I would call it the OO/component slice through
the picture I drew above.
I looked at GNOME's config system, and believe that I could
plug in behind their interface and then call a new interface to
the described generic config service. The same approach could also
be taken with KDE, i.e. a translator library could redirect the
organization(GNOME, KDE, ...) dependent config service to the
generic config service. The nice thing is that it might then be possible
to write apps that use the same config base in either windowing/component
system. This could provide one of the steps required to do real time
switching between KDE/GNOME. That's not specifically a goal, just a
side effect. I'm sure other steps would be required to make an app
window system independent.
I want to be able to distribute a small source library that
developers can compile into their apps, thus not
requiring any system support. My application has a wider
audience than just Linux and is based on Motif. While
I could convert to GNOME or Qt/KDE I would lose some
platform agility in doing so.
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: George MacDonald <[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 05:56:54 GMT
Frank Sweetser wrote:
>
> George MacDonald <[EMAIL PROTECTED]> writes:
>
> > > hmm... it should be fairly easy with a single config file. what kind of
> > > scenario do you see where it would be updating multiple config files as a
> > > single operation?
> > >
> >
> > Hmm, lets see. If I create a "component" that is a file selector and I
> > create a seperate resource file for that component. Then include
> > that resource file in any app resource file that uses the new file
> > selector component. This allows me to set a resource for the new
> > file selector Class in one place. Now lets say I'm running an app
> > and I want to change one of the resource values for the new file
> > selector. In this case lets assume I have a favorite places in
> > the file selector. I may want to update the Class(the new place
> > is visible in all apps) or update the instance(the new place
> > only shows up when used via the current app) or I may want to
> > do both.
> >
> > Also I may want to update several resources at the same time
> > in several files.
>
> hrm... okay. so this would then require 1) some way of logically combining
> multiple files in to a single 'virtual' config, and 2) locking the entire
> group, making sure that there are no files shared between that group and
> any other groups that are locked... could be hairy with files, should be
> easier with databases, no idea about CORBA :P
>
Could create a new hierarchy with just the changes. Then push the changes
in the front of a path of configs to merge together. Then only have to worry
about someone else creating another branch at the same time. Could
allow either locking or open changes with a merge done automatically
and user notified on conflicts(or let latest save win a conflict).
This is the stuff of DB table/row locking and commit/rollbacks. All
of which can be done in a fs using cow, lockfiles, ... The biggy
is having at least one kind of atomic operation i.e mv or rename.
Of course it's way slower on a fs, but we are talking user speeds
for the most part. If the need is really there, i.e large systems/
networks or many config changes then use a DB &/CORBA.
CORBA has transaction services for this kind of stuff, but this
is not nesc part of every corba implementation.
> > > that is because so many of the values are shared (byte counts, packet
> > > counts, errors, etc). for more advanced, often proprietary stuff (filters,
> > > security) the software must be aware of the meanings of those values.
> > > trust me, we've had to upgrade the NMS software on our machine here to deal
> > > with new hardware in anything but the basic generic functions several
> > > times...
> >
> > Yes but a generic NMS system can be built, like OpenView ..., that can
> > be used as the framework to plug in device specific modules. Even
> > without the modules some generic functionality can be used on the
> > new device. i.e.
> >
> > Monitoring/Logging changes
> > Graphing values
> >
> > Also devices that have a common set of values can use existing
> > MIB's and thus use existing tools.
>
> exactly. my feeling is that there won't be very much of the same overlap
> in existing apps, though if common toolkits were modified to use it....
Well hopefully we move to a more component based model with GNOME/KDE.
Then there will be much more common config info, in fact I think both
of them already have some kind of config components. What would be really
cool is to have GNOME components in a KDE app or visa versa.
>
> > >
> > > however, to get back OT, i don't think this would be an issue, as the
> > > config library would simply be handing back values for the requested keys
> > > and letting the application deal with 'em from there.
> > >
> >
> > It would be nice to be able to leverage configuration components. Lets say
> > a user want's to define a color for the background of a widget.
> > In such a case one could have a "color selector" component that does
> > the selecting. Thus a developer would not need to write one. Also
> > if done right new color selector components could be written and
> > plugged into apps at run time.
>
> hmm... so, are you suggesting that in addition to the config data, certain
> components would also contain code for configuring that code? <hmm...> if
> the library could deal with raw binary data, then it could be treated as
> just another configuration entry.
It doesn't have to be binary data, all binary data can be represented as
ASCII. Remember one of the goals is to make the config info
understandable to users. I am thinking the data can be typed or
more appropriately "classed". i.e. the config files contain chunks
of persistent config objects.
Lets say one of the attributes is a color, then it would be nice to
have a color selector component that could be used when a user
decides to set a color preference. It would be one less thing for
developers to develop again and again. In fact I think GNOME
has something like this.
>
> > > also, what language were you planning on using?
> > >
> >
> > I was hoping to be language neutral, i.e. define an interface
> > to a config service and then do language bindings for
> >
> > C, C++, Java, Python, Shell ...
> >
> > Also to be Object Oriented but not requiring an OO language, i.e.
> > the half way approach taken by Xt, GTk+ etc.
>
> i like it! make another nice example that OO is more than some extra
> syntactic sugar in the latest language =)
>
> > > i'm not sure it would be worth it to develop a new protocol and
> > > accompanying server for it. to me, the most useful ones would be local
> > > files, SNMP (fairly lightweight, for smallish networks primarily), SQL so
> > > you can store 'em on a full-featured database for better scalability,
> > > backups, transactions, etc, and HTTP (to make it simply, could use the same
> > > file format as local files... would make writing the config files a little
> > > harder - WebDAV, perhaps?) primarily for roaming users to get around
> > > firewalls and low bandwidth configs. CORBA sounds like it would also be
> > > well suited for this, and it seems to be getting more common nowadays.
> > >
> >
> > I think you pretty much nailed what I was thinking. I would prefer to
> > leverage off of existing implementations as much as possible, but
> > can't find one protocol that does what I want. Well CORBA does but
> > thats one heck of a requirement for an app that only has a couple
> > of settings. Thus I don't want to be bound to CORBA, but at the same
> > time think it could be used for the higher end of the service.
> >
> > > i definatelly like the way this project is looking.... i'd be willing to
> > > contribute, if you're interested.
> >
> > Great! I am putting together a web site for this purpose, and have started
> > to put togther a feature list ... See
> >
> > http://at.home/gmd/opStore/
>
> this web site doesn't seem to be up ATM.... :(
Oops should be
http://24.1.97.22/gmd/opStore/
>
> > This is a very rough first cut and everything is subject to change.
> >
> > I am shooting to get a project definition in the next week or two and
> > an outline of an architecture spec by the end of the month. I could
> > see a basic library coming together in a month or two and a core
> > service framework in 3-6 months(depending on how many people
> > want to get involved). This estimate does not include many of the
> > advanced features CORBA/HTML/SNMP interface modules etc. But
> > would provide the architecture/plugin points for them.
> >
> > My primary interest is in a config system for an app I am developing,
> > i.e. treeps
> >
> > http://24.1.97.22/gmd/tps/treepsfm.html
>
> and neither is this one :(
Hmm, that one should be. Could you try again and let me know? I check the
log and got some hits today and the server seems ok just now.
>
> > which is already very configuration dependent and about to become much
> > more so. My needs for it exceed all current config systems I find, so
> > am going to write my own anyhow, may as well make it useful for others
> > and extensible for later needs. It appears it's also something that
> > needs doing!
> >
> > I am going to dedicate 6 months of full time activity to this task
> > and am open to either joining a project or coordinating it. Anyone
> > who wants to help is welcome.
>
> don't think i'll be able to put that much in, but i'll be glad to help
> out with what i can.
Great
First task is to get together a good description of the problem to
be solved. Then put together a list of features/ideas. I have started
this, it's still very rough. Have a look at the web site and tell me what you
think.
>
> another point i came up with while playing with the libprofile stuff - that
> of getting info out of a node some arbitrary levels deep, without manually
> iterating down the tree. i was thinking of simply passing a string, with
> each progresive node name, with some single char delimiter, like a file
> path. sound reasonable?
Well, I'm jumping ahead a bit. I was thinking that the file format
could be similar in some ways to the X resource files. In those
files there are class and object_instance names used to specify
a "path" to a resource. These are "." seperated, although it
may be better simply to say there is a seperator character used,
and allow it to be definable.
Are you familiar with X resources? How about ini file formats?
I am much more familiar with X resources than ini file format,
and realize they are not the easiest to understand.
I do like the object/class naming system. The wild carding is
very powerful but a bit confusing since it's not obvious what
they match unless you know a programs widget hierarchy.
The big drawbacks with X resources are the lack of update
capability(from a running application) and no
type information is available for the values(hence no
checking can be done to determine if the fields are valid
until a program is run).
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
** 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
******************************
