Linux-Development-Sys Digest #279, Volume #6 Thu, 14 Jan 99 14:14:09 EST
Contents:
Re: virtualizing i386-linux (Christopher B. Browne)
IP / ICMP checksum calculation ("Sander Pilon")
Re: - deprecated - why? (Stefan Monnier)
Re: Obtaining MAC address from remote computer ("Sander Pilon")
Re: Anti-aliased fonts (Brian A. Pomerantz)
Re: Shared memory between PCI device and application. (Robert Kaiser)
Secuity hole with perl (suidperl) and nosuid mounts on Linux (Brian McCauley)
Re: Registry for Linux - Bad idea (Christopher Browne)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Subject: Re: virtualizing i386-linux
Date: 14 Jan 1999 14:02:26 GMT
Reply-To: [EMAIL PROTECTED]
On 14 Jan 1999 12:57:00 GMT, M Sweger <[EMAIL PROTECTED]> posted:
>M Sweger ([EMAIL PROTECTED]) wrote:
>
>: I believe the way IBM does it for VMS is that the microprocessor has
>: special priveledged instructions for kernel control and IO so that
>: there won't be any conflicts. This allows them to run multiple versions
>: of VMS (production vs. experimental version) and/or Unix side by side.
>
>Sorry, I mean't to say MVS with TSO!
Um, yes. I figured it wasn't too much worth mentioning. It is entirely
unfortunate that IBM and Digital named OSes *so* closely. (And I have an
axe to grind with folks at work that apparently can't tell the difference
between Network File System and National Science Foundation, but that's
another story...)
>: Anoter possibility is to write a micro kernel which is based on the
>: Corba model. Therefore, each object running off the Corba ORB can be
>: an OS [version] of Linux or, Linux and Windows or anything else
>: simultaneously. Hence, the virtual networking between the different
>: OS versions is done already for you by the Corba ORB's Object to
>: object communications (OS to OS communications) via RPC, IIOP etc.
>
>Moreover, if each object [OS] wants to talk to the hardware, it
>would instantiate a Corba object requesting hardware service. Then
>the Corba Object scheduler would use the Corba services to actually
>perform the hardware request. This is similar to batch jobs in terms
>of requesting hardware access.
This essentially represents Yet Another Way of Multiplexing.
Parallelize via turning everything into a separate CORBA object.
Upside: Certainly an interesting idea. Parallelism comes "for free" (as
always, with the cost of having to partition the application).
Downside: While this approach doesn't mandate pushing the ORB into the
kernel, an equivalent thing happens as the ORB is treated by its
applications as if it were an "OS kernel."
I'm not convinced that we have a sufficiently robust ORB yet to support
running big apps this way.
--
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: "Sander Pilon" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: IP / ICMP checksum calculation
Date: Wed, 13 Jan 1999 19:26:52 +0100
I'm looking for *C* sourcecode (for Linux) that RE-calculates
the IP and ICMP packet checksums after modification.
(NAT)
Anyone?
Thanks,
Sander
[EMAIL PROTECTED]
------------------------------
From: Stefan Monnier
<[EMAIL PROTECTED]>
Subject: Re: - deprecated - why?
Date: 14 Jan 1999 09:48:03 -0500
>>>>> "Alan" == Alan Curry <[EMAIL PROTECTED]> writes:
> I second that emotion.
Stop whining before you even know what's happening:
ps isn't switching from BSD to SysV. Rather it's adding SysV while
keeping BSD. Digital Unix and probably other unixes have been doing it for a
while now and I believe it's the Unix98 behavior also: options with a leading
- are SysV options, while options without are BSD-derived.
So `ps aux' will work, while `ps -aux' will not.
Stefan
------------------------------
From: "Sander Pilon" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: Re: Obtaining MAC address from remote computer
Date: Thu, 14 Jan 1999 17:23:36 +0100
>Sander Pilon wrote:
>
>[ ... ]
>
>> A packet arrived on eth0, I'm going to forward it to eth1 and I have to
>> insert a new MAC
>> address.
>
>Where do you want to do this?
>In userland, you don't have to do it, since the MAC layer is
>inaccessable to the user. You use IP addresses.
>
>In kernel, you use the arp module to resolve IP addresses.
Userland, with packet sockets.
With packet sockets the MAC layer *IS* accessible. I wrote a program
that puts raw ethernet packets on the wire, with random MAC addresses
and it works perfect. Now, I want to do this with "real" mac addresses...
I "found" a solution though, but it's far from perfect. Look in
/proc/net/arp, there
you will find the ARP cache for the kernel. Combined with a cache in the C
program this will have to do.
Sander
------------------------------
From: [EMAIL PROTECTED] (Brian A. Pomerantz)
Crossposted-To: comp.os.linux.misc
Subject: Re: Anti-aliased fonts
Date: 14 Jan 1999 17:00:34 GMT
In article <[EMAIL PROTECTED]>,
Kaustav Bhattacharya <k, dot, bhattacharya, at, bbc, dot, co, dot, uk> wrote:
>I just installed Red Hat Linux 5.2. It works great. Being a long time
>Risc OS (Acorn) user I miss the availability of a system wide/GUI
>standard for use of anti-aliased fonts. Is there a way (a WM? or
>something) of getting fonts to anti-alias under X or another WM? I
>remember reading somewhere that there was a way of doing this?
There is work in progress for the 4.0 release of XFree86 that will
allow anti-aliased fonts. This will be in the form of a new X
extension. So, any app that you have will more than likely have to be
aware of the X extension and utilize it. Of course, it is work in
progress and things will change, but don't expect to see anything
before next summer at the earliest.
BAPper
------------------------------
From: [EMAIL PROTECTED] (Robert Kaiser)
Subject: Re: Shared memory between PCI device and application.
Date: 14 Jan 1999 16:27:19 GMT
In article <77ja03$2u7$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Greg Johnson) writes:
> Thanks, but I am not wanting to apply any patches to the kernel since
> it will make it that much harder to port the code to newer kernel
> version when the need arises. Also, I am not wanting to specify
> anything at boot time like reserving a part of memory If I can avoid
> it.
>
I'm afraid you'll have to apply a patch as the current Linux kernels
(amazingly) don't have the ability you want. Apart from the bigphysarea
patch there's another one available at ftp://ftp.sysgo.de/pub/Linux/
I think this one is more like what you want (i.e. you can pass any
user-space pointer down to a driver and let it DMA to/from that
memory directly).
Both the bigphysarea patch and mine are pretty self-contained. Thus
it is usually easy to move them from one kernel revision to another.
I once offered this patch to be integrated into the standard kernel,
but Linus rejected it.
================================================================
Robert Kaiser email: rkaiser AT sysgo DOT de
SYSGO RTS GmbH
Mainz / Germany
------------------------------
From: Brian McCauley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.lang.perl.misc
Subject: Secuity hole with perl (suidperl) and nosuid mounts on Linux
Date: 14 Jan 1999 17:58:15 +0000
The suid script emulation in Perl 5.0004_4 (as found in SuSE Linux 5.3
and doubtless other Linux distributions) fails to take account of the
nosuid mount option on filesystems.
This means that it is trivial for a resourceful user to hide a setuid
perl script on a CD or floppy and then use it to become root. Many
systems are (even by default) configured to allow users mount floppys
and CDs nosuid.
The most obvious fix to Perl for this would be (where available) to
use fstatvfs() (as defined in SUSv2) to determine if the script is on
a filesystem that is mounted with the nosuid option.
Unfortunately fstatvfs() is not implemented in Linux (as of 2.2pre1).
It would not be difficult to add the new system call. Indeed the
existing fstatfs() implementation could simply be modified to
implement fstatvfs() semantics and both syscalls could then point to
the same code.
This vulerability will exist in all Unicies that use a user-space
implementation of suid-scripts and impelment a nosuid mount option in
such a way that it does not modify the values returned by fstat().
It is worth noting that that other suid-aware script-interpreters will
probalby also display this vulnerability on Linux because of the
absense of fstatvfs().
--
\\ ( ) No male bovine | Email: [EMAIL PROTECTED]
. _\\__[oo faeces from | Phones: +44 121 471 3789 (home)
.__/ \\ /\@ /~) /~[ /\/[ | +44 121 627 2173 (voice) 2175 (fax)
. l___\\ /~~) /~~[ / [ | PGP-fp: D7 03 2A 4B D8 3A 05 37...
# ll l\\ ~~~~ ~ ~ ~ ~ | http://www.wcl.bham.ac.uk/~bam/
###LL LL\\ (Brian McCauley) |
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 14 Jan 1999 03:47:01 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 13 Jan 1999 05:12:25 GMT, George MacDonald <[EMAIL PROTECTED]> wrote:
>Christopher Browne wrote:
>> On Thu, 07 Jan 1999 10:25:28 GMT, George MacDonald <[EMAIL PROTECTED]> wrote:
>> >Christopher Browne wrote:
>> >>
>> >> On 05 Jan 1999 19:59:16 -0500, Frank Sweetser <[EMAIL PROTECTED]> wrote:
>> >> >Tristan Wibberley <[EMAIL PROTECTED]> writes:
>> >> >> 2) then a couple of libraries for parsing flat text will be most
>> >> >> appropriate no? Simplest to implement.
>> >> >
>> >> >agreed. this would be the first logical module to implement. i actually
>> >> >have two of them in front of me now (profile code from the kerberos package
>> >> >courtesy ted t'so, and libconfig from sunsite), one of which will probably
>> >> >end up getting stuffed into the flat text module.
>> >>
>> >> Indeed.
>> >>
>> >> Note that there will likely be two pieces:
>> >> a) Read the config, and
>> >> b) Write the config.
>> >>
>> >> The UNIX "approach" has been for these to be distinctly separated.
>> >> Which is, for things that are commonly referenced, but seldom changed, a
>> >> Good Thing.
>> >
>> >This model works well for CLI based users who know the unix "model".
>> >However newer users and GUI based users have a learning curve to be
>> >able to do the "write" part.
>>
>> I'm not talking about applications. I'm talking about the way it works
>> "behind the curtain."
>>
>> It doesn't matter very much, when designing the low level part, how the
>> "user side" works.
>>
>> If the system provides a "pretty, Barneyfied tool," the user will not
>> ever need to touch the data by hand, which means that the user *doesn't
>> care* about the data representation.
>
>Most end users. Some will use the CLI and go looking for config files
>simply because that's the way they are used to doing things or they
>like to "know" how it works.
Those that want to intrude by hand will obviously need to care.
>> From a design perspective, the first thing we need to do is establish a
>> good data representation. And *then* figure out how to make it "Barney
>> friendly." Looking at Barney first represents a wonderful opportunity to
>> misdesign things.
>
>Well I agree a good data representation is needed, but what data are we
>going to represent? Do we need to represent
>
> key's and string values which are "typed" by the app
> key's and lists of strings typed by the apps
> keys and typed values
> key's and lists of returned typed values
>
> keys' and a list of objects some of which are values
> some of which is meta data.
>
> Do we need to support a redirect or link to say get the value
> from somewhere else?
>
> How do you lavel something as final, is that meta data on a field?
>
>What do we call these, attributes, fields, objects. Exactly what does
>the term we use mean? ... Is it object oriented, are there class definitions,
>are there methods? can methods be defined, overridden ...
>
>Many questions, some of which are dependent on the higher level model
>we decide on.
Note that none of these questions ask anything about the GUI
configurator's user interface.
>> >platform and it would be nice to be able to minimize the required learning
>> >for users who are task oriented. So one big question is, do you want to
>>
>> Data representation != Tools to manipulate data.
>>
>> > support a newer GUI based model for "end users"
>> > support the CLI model where users work with CLI and file tools
>> > support both
>> >
>> >I think doing both is the best approach.
>>
>> I agree that having both "powerful" and "Barney-friendly" data
>> manipulation tools is a good thing. That is orthogonal to data
>> *representation.*
>
>Well yes and no. For example do you support unicode values? if so
>by hex? Following the HTML way? ...
>
>Do you use SGML to define the grammer ... Or follow a C++ type
>class definition, or a CORBA interface spec, ...
The matter of having a "configurator tool" is *still* orthogonal to the
data representation. So it's not "yes and no." It's simply "yes."
>> >> Everyone seems to want to come up with a "sexy" system that will
>> >> represent the "be-all and end-all."
>> >>
>> >> "I'll come up with the perfect configuration system, and it will make
>> >> me famous!"
>> >
>> >Even the best config system would get you a wet rag response! Don't
>> >count on getting famous out of it, you may help a lot of developers
>> >and end users, but most likely they won't even give it a passing
>> >thought. In fact if it's done well, it will be invisible.
>>
>> Which is to say that from the enduser's perspective, a how data is
>> represented will be invisible. Which is what I said earlier.
>
>For GUI users yes, for CLI users not nesc.
Obviously anyone wanting to "head behind the curtain" needs to have an
understanding of the details that will sit behind the curtain.
>> >> Unfortunately, actually implementing such a universal thing requires
>> >> that a *lot* of programs be modified. Which requires more effort than
>> >> anyone is likely to be willing to employ. It's *not* as simple as
>> >> coming up with the "perfect config system."
>> >
>> >More wisdom, any good solution will find a way to work with the
>> >existing mechanism and extend it to be better. Also as you
>> >say it should not take much effort on the part of a developer
>> >otherwise they won't bother. I belive they should get something
>> >out of using a config service and not the other way around.
>>
>> True.
>>
>> Which means that a good API will allow a programmer to construct some
>> common tools that can manipulate multiple data sources.
>>
>Yup, but as you say later. First things first, we need an architecture
>that can cope with multiple data sources, perhaps translating to some
>neutral data format.
>
>> >> If, in contrast, a scheme is set up that is *useful enough* and
>> >> *convenient enough* that it convinces *SOME* developers to adopt it,
>> >> thereby reducing the number of completely independent configuration
>> >> systems, that's GOOD ENOUGH.
>> >>
>> >> We don't need a "Unified Field Theory" of configuration systems; we need
>> >> something that's Good Enough, and perhaps that's somewhat better than we
>> >> have now.
>> >
>> >I tend to think through a problem to come up with a nice clean conceptual
>> >solution. This includes describing the *ultimate* desired solution.
>>
>> But when you talk about an "*ultimate* desired solution," you are
>> assuming something akin to a "Grand Unified Field Theory," where there
>> will be a single clean conceptual solution.
>>
>> I claim that it is not proven that that single solution exists.
>
>Well I'm striving to come up with a paragraph or two that can define
>the solution. It needs to be clean, clear and easily communicated. It's
>important to be able to set a vision or framework in someone
>elses head so you can hang the details on it.
>
>Saying it's a distributed hierarchical persistent network
>based object storage system doesn't quite cut it.
True enough; it will obviously be necessary to be a bit more specific
than that. Once choices are made, that restricts later choices.
>> There are diverse varieties of configuration, which means that fitting
>> them all onto one data store may be like the legendary Procrustean Bed,
>> where Procrustes would modify peoples' sizes so they'd fit. Stretching
>> those that are too short, and chopping bits off of those that are too
>> tall.
>
>Hmm, I guess he never heard of folding space.
Not in those days... Greek legends predate modern physics...
>> >> Make sure it is documented clearly how this is to work, so that it is
>> >> *CLEAR* which files will be evaluated in what order. The problem with
>> >> (in contrast) X resource information is that the order of evaluation is
>> >> *not* clear.
>> >
>> >How so? I thought it was .Xdefaults, any xrdb'ed values, app-defaults,
>> >$HOME/AppName, command line, internalized defaults
>> >
>> >Well ther is XAPPRES and the localizing, ... Jesh that's at least 8
>> >levels!!!
>>
>> That there are on the order of 8 levels, and that people have a hard
>> time remembering which goes in which order, is very much the point.
>
>I typically only use four of them!
That's fine; there's still a pile of them, which represents considerable
complexity.
>> I don't much care if we're using 'dot files' in $HOME, or files in
>> $HOME/etc, or $HOME/GNUStep/...; the point is to have *some* sort of
>> convention so that it is easy to search for configuration information.
>
>Using a dot directory in $HOME is the typical way to handle lots of
>config info. Examples are CDE, GNOME, ... Using the . allows the
>file to be "hidden", well at least from a normal ls. It's not the
>best way to do it, but that's the convention. Invading the
>users name space i.e. a non dot file/directory is considered a
>real no-no.
I hear you; one invasion isn't a horrible thing, and remember that
NeXTStep derivatives all have some sort of $HOME/NeXTStep/ or
$HOME/GNUStep/ or $HOME/OpenStep directory where their "stuff" goes.
If, by introducing one directory, we get more manageable systems, that
seems to me to be a reasonable compromise to have taken.
>> >Finally my $HOME already has way to many .$app dirs, too many
>> >for my tastes, hence one of the reasons for my desire to push
>> >them down to ".userStore/Applications".
>>
>> The huge number of .dot .files that collect in $HOME is quite annoying.
>> It would be nice if they hid under a directory; whether that be
>> $HOME/.userstore/, or $HOME/etc/, or $HOME/GNUStep/, I do not really
>> care which is used.
>>
>> - $HOME/.userstore/ has the non-salutory effect that it is somewhat
>> "hidden."
>>
>We can configure the name, that way if/when someone comes up with a
>better one we can say set it to what they want. Could even allow the
>user a environmental variable i.e. USER_STORE=".myStore"
Having this be configurable is indeed attractive.
--
Real Programmers use: "compress -d > a.out"
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
** 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
******************************
