Linux-Development-Sys Digest #270, Volume #6 Wed, 13 Jan 99 09:14:05 EST
Contents:
Re: virtualizing i386-linux (Ross Vandegrift)
Re: disheartened gnome developer (Marco Anglesio)
Re: iso9660: time-stamp mismatch/bug? (Villy Kruse)
Re: - deprecated - why? (Josef Moellers)
/dev/dsp and /dev/audio in OSS sound engine (Christian Uhde)
Re: disheartened gnome developer (Michael Hasenstein)
2.2.0pre6: No broadcasts on ethernet (Rainer Krienke)
Re: silly question (Tristan Wibberley)
Re: How to share memory between device driver and user space app? ("jian.zhang")
moving linux to different partition (richard hankins)
Re: Registry for Linux - Why? (Christopher Browne)
----------------------------------------------------------------------------
From: Ross Vandegrift <[EMAIL PROTECTED]>
Subject: Re: virtualizing i386-linux
Date: Tue, 12 Jan 1999 18:41:59 -0500
Reply-To: [EMAIL PROTECTED]
> I'm sure there are lots of pitfalls, and maybe it can't even be done on
> a [345]86, but looks nice, doesn't it?
Actually, I recall a thread somewhere about virtualizing an ix86
processor. Most people seemed enthusiastic about it, until someone
explained in clear detail why this couldn't be done. I don't remember
exacty what, but it specifically had to do with one of the registers
being dependant on being on the physical processor (well, that's kinda
like it). I wish I remembered more because it was a very interesting
thread, and I would search DejaNews for this.
--
Ross Vandegrift | Eric J. Fenderson
alt.binaries.punk: for those of us too
punk to pay money for the music.
------------------------------
From: Marco Anglesio <[EMAIL PROTECTED]>
Subject: Re: disheartened gnome developer
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Date: Tue, 12 Jan 1999 16:15:26 GMT
In comp.os.linux.development.system steve mcadams <[EMAIL PROTECTED]> wrote:
>>It would be nice, but any company buying your
>>code will still sign a support contract because they can't see the future.
> benefits of open-source (which I equate with GPL, I better look some
> "open-source" references and see how -that- is defined) was that you
> could fix the code yourself.
You certainly can. And fork development, if you want to. However, it will
probably cost a lot less to buy the support contract (even an open-ended
one) than task a f/t staff member to support a largely documentation-free
piece of code. Conversely, if you don't offer any support services, not
even documentation, and feel like doing development only (which was your
original complaint), you might get business on a frosty friday in hell.
> They probably had lots of strategies.
They did. Although the R&D that resulted in the M/360, IIRC, cost a fair
sight more than the Manhattan Project, was, I believe, the costliest
non-governmental research project ever at that time, which they made back
in spades, by hook or by crook.
> I think the one that got them
> in trouble was that they made purchasing prohibitively expensive in
> order to push their leasing business. Sort of like uncle bill trying
> to get people to pay a monthly Windows Tax.
People would, though, because it seems cheaper. Also, it allows you to get
something without taking a chunk out of your (possibly nonexistent)
capital budget. For that matter, MS does do licensing in a similar fashion
by allowing businesses to buy a site license for a specified amount of
time - although I daresay they get paid in advance for it.
It also allows them to leverage (okay, let's be honest: firehose) their
upgrades onto the business market, creating sales momentum for each new
release and incompatible file format.
marco
--
Marco Anglesio Like Captain Idiot
mpa at the-wire dot com in Astounding Science comics
http://www.the-wire.com/~mpa (The Manchurian Candidate)
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: iso9660: time-stamp mismatch/bug?
Date: 13 Jan 1999 13:16:44 +0100
In article <77hkcf$8dl$[EMAIL PROTECTED]>,
Villy Kruse <[EMAIL PROTECTED]> wrote:
>
>The time fields on iso9660 file systems do have a variable for specifying
>the time zone. I'm not sure if that means that if this field is zero
>that the time stamps are supposed to be in UTC time. I beleive that
>the linux code treat the time stamps as UTC. It wouldn't supprice
>me if windows ignores the time zone issue when creating CD images.
>Actually this would be a function of the CD formatting software.
>
>
>Someone should consult the ISO 9660 text to see which is correct.
>
The ISO 9660 standard document doesn't realy say.
However, mkisofs assumes that the time stamps are wall clock time,
and the timezone variable stored in the directory should be subtracted
from the time to get UTC time. A comment in mkisofs.c suggest that the
isofs code in the kernel still does it the wrong way.
As taken from /usr/src/linux-2.0.35/fs/isofs/util.c
int iso_date(char * p, int flag)
{
int year, month, day, hour ,minute, second, tz;
int crtime, days, i;
year = p[0] - 70;
month = p[1];
day = p[2];
hour = p[3];
minute = p[4];
second = p[5];
if (flag == 0) tz = p[6]; /* High sierra has no time zone */
else tz = 0;
if (year < 0) {
crtime = 0;
} else {
int monlen[12] = {31,28,31,30,31,30,31,31,30,31,30,31};
extern struct timezone sys_tz;
days = year * 365;
if (year > 2)
days += (year+1) / 4;
for (i = 1; i < month; i++)
days += monlen[i-1];
if (((year+2) % 4) == 0 && month > 2)
days++;
days += day - 1;
crtime = ((((days * 24) + hour) * 60 + minute) * 60)
+ second;
if (sys_tz.tz_dsttime)
crtime -= 3600;
This is probably meaningless ^^^^^^^^^^^^
/* sign extend */
if (tz & 0x80)
tz |= (-1 << 8);
/* timezone offset is unreliable on some disks */
if (-48 <= tz && tz <= 52)
crtime += tz * 15 * 60;
Should subtract here ^^^ not add.
}
return crtime;
}
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: - deprecated - why?
Date: Wed, 13 Jan 1999 12:55:59 +0100
Steve Carter wrote:
>
> [originally posted to comp.os.linux.development.apps oops!]
>
> Why in the world does linux tell me off for typing
>
> ps -e
>
> when it knows full well what I mean, other unices require the minus, and
> the minus is required or at least permitted by just about every other
> command.
The manual says this is "because in the future, a `-' will be used to
indicate Unix98-standard command-line arguments, while no `-' will
indicate the current ``extended BSD'' style of command line arguments."
As you have noticed, "ps" does indeed know what you mean, it just tells
you that one day YOU won't know what you mean (SCNR).
--
Josef Moellers [EMAIL PROTECTED]
UNIX - Live free or die!
PS Dieser Artikel enthaelt einzig und allein meine persoenlichen
Ansichten!
PS This article contains my own, personal opinion only!
------------------------------
From: Christian Uhde <[EMAIL PROTECTED]>
Subject: /dev/dsp and /dev/audio in OSS sound engine
Date: Wed, 13 Jan 1999 11:12:01 +0000
hi all,
how does the OSS module handle the /dev/dsp and /dev/audio devices ?
there is no option available in the kernel setup, in 2.0.x it is.
if i try to write into the device, following error occurs :
bash: /dev/dsp: Operation not supported by device
any clues ?
bye
chris.
--
IT Support Grp, Department of Mathematics - Bonn University
{PGP|GPG} key available - ICQ #5068320
------------------------------
From: Michael Hasenstein <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Wed, 13 Jan 1999 13:40:03 -0800
Reply-To: [EMAIL PROTECTED]
Duncan Rose wrote:
> I don't think you are right. According to the GPL, under which terms the RH
> software you're talking about is distributed, if the existing (freely
> available)
> source is used to build the new version, the new version must be GPLed
> too (in my understanding -- correct me if I'm wrong).
Only if the distributor is not the owner. As owner you can change
licences as you wish. You can't take away what you already gave away,
that's all. GPLing doesn't mean you give up your copyright. That has
been discussed a thousand times here (that's why I know it)!
--
Michael Hasenstein; Siemens SBS
http://www.csn.tu-chemnitz.de/~mha/
Private Pilot (ASEL) since 1998
------------------------------
From: [EMAIL PROTECTED] (Rainer Krienke)
Subject: 2.2.0pre6: No broadcasts on ethernet
Date: 13 Jan 1999 13:32:24 GMT
Hello,
IŽd like to know if anyone else has the same problem, or a hint what to
do:
My Linux box is part of a LAN. The network is build by fast ethernet.
With the old 2.0.36 kernel there were no problems. When i tried to
upgrade to a 2.2.pre or an older 2.1.x kernel I have one big problem. My
machine seems to be unable to send boradcasts on the net. I can ping a
particular machine and everything else on the local net as usual exept
for broadcasts. If I say ping <broadcast adress> the only answer I get
is of my own machine. All the other machine in the same subnet (not
behind a router) of our local net do not hear the broadcast.
Using Kernel Version 2.0.36 this problem does not exist.
Any idea?
Thank you
Rainer Krienke
--
=====================================================================
Rainer Krienke [EMAIL PROTECTED]
Universitaet Koblenz, http://www.uni-koblenz.de/~krienke
Rechenzentrum, Voice: +49 261 287 -1312
Rheinau 1, 56075 Koblenz, Germany Fax: +49 261 9119-495
=====================================================================
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: silly question
Date: Tue, 12 Jan 1999 02:19:25 +0000
Reply-To: [EMAIL PROTECTED]
mlw wrote:
>
> Josef Moellers wrote:
> > It's a philosophical question.
> Why is it a philosophical question. There is a task which is usefull
> which no utilities perform easily. Yes, any number of utilities can be
> strung together to do it, just not easily.
>
> Why does UNIX have 'rmdir' and 'rm' both can remove directories?
> Why are there so many shells?
>
> Because it is this wealth of utilities that makes UNIX easier to use
> than other OS platforms.
> >
> > DOS has the approach that there has to be a specific tool for each and
> > every purpose (... Gates can think of). If a user wants to do something,
> > there has to be a ready-to-use tool. If there is no tool, you can't do
> > it! So there is no use for a scripting language, hence there is none.
>
> This is not true. DOS, Windows and NT support pipes. And one can type:
> dir | sort | more
> in DOS, Windows and NT, UNIX does not have a lock on these features.
>
> >
> > UNIX has a tool-based approach that you can build a tool for a specific
> > purpose from simpler tools. In order to do so, you need a powerfull
> > scripting language, hence there are even a number of shells!
>
> >
> > "Finally, the UNIX system provided a new style of computing, a new way
> > of thinking of how to attack a problem with a computer. This style was
> > based on the use of tools: using programs separately or in combination
> > to get a job done, rather than doing it by hand [pointy-clicky], by
> > monolythic self-sufficient subsystems [xcopy], or by special-purpose,
> > one-time programs." (R. Pike, B.W. Kernighan)
>
> XCOPY is not a monolythic self-sufficient subsystem any more than is rm
> or cp. Infact, cp is deficient in that it can't do what xcopy does.
cp isn't deficient, cp copies. In order to be consistent with it's name
(and therefore have a decent interface), it doesn't travers directory
structures comparing files as it goes - it just copies.
find, however, *does* travers directories comparing files as it goes.
so if you combine the two you get the desired functionality into a file
'xcp':
===========
#!/bin/sh
find ./ -name "${1}" -exec cp -afP \{} "${2}" \; # archive, force, Path
maintained
===========
this takes the first argument as the glob pattern (remember to escape it
- depending on your shell), the second argument specifies the top
directory of the new tree.
It will overwrite existing files, preserve the mode/uid/gid/timestamp,
and preserve hard/soft links - I don't know what happens with the links
if you're copying to a fat filesystem for instance.
--
Tristan Wibberley
------------------------------
From: "jian.zhang" <[EMAIL PROTECTED]>
Subject: Re: How to share memory between device driver and user space app?
Date: Wed, 13 Jan 1999 08:49:15 -0500
Arun Sharma wrote:
>
> "jian.zhang" <[EMAIL PROTECTED]> writes:
>
> > Help!
> > Hi, currently I am developing a device driver and one application,
> > The device driver and application always exchange some data, so I want
> > to share memory between driver and application? How to do this? I only
> > know how to share application between two user space applications.
>
> The application passes pointers to the shared area to the device
^^^^^^^^^^^
The real problem is how to setup the shared area between a kernel
device
driver and a user space application. In user application, after open
device
driver file, I call mmap try to setup the share memory, the linux
kernel
will call my driver's mmap() function. But I don't know how to map the
user area's VMA to one memory block of my device driver. I try use
remap_page_range(), second parameter pass the address of memory block ,
It doesn't work. What I do like this:
// Kernel device driver.
char DeviceBlock[4096];
int my_mmap( struct inode * inode, struct file * file, struct
vm_area_struct * vma)
{
/* It won't work */
remap_page_range( vma_get_start(vma),
DeviceBlock,vma_get_end(vma)-vma_get_start(vma),
vma_get_page_prot(vma) );
}
// User App.
char * pShare;
pShare=mmap(NULL,4096,PROT_READ|PROT_WRITE,MAP_SHARED,hDeviceFile,0);
Problem: How to map the vma in my_mmap?
> driver through read/write/ioctl interfaces.
>
> -Arun
------------------------------
From: richard hankins <[EMAIL PROTECTED]>
Subject: moving linux to different partition
Date: Tue, 12 Jan 1999 21:09:26 -0500
Is it possible to correctly copy my complete linux installation,
currently on one small partition, to another partition?
How do I handle the /dev and /proc directories?
Thanks,
Rich
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Registry for Linux - Why?
Date: 13 Jan 1999 02:22:52 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 8 Jan 1999 21:09:46 GMT, TGAPE!
<[EMAIL PROTECTED]> wrote:
>In article <76n2gi$pc$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>>Christopher Browne <[EMAIL PROTECTED]> wrote:
>>> It would thus be appropriate to provide a Sample Implementation that
>>> clearly defines a combination of:
>>> - API (so that applications may conveniently get at config data without
>>> having to worry about Physical Representation),
>>
>>I really think that using an API call to get this config info is a bad
>>idea... I think this information would best be served in a plain text
>>file... so it can be edited with scripts, and FIXED with text-editors. We
>>all agree that putting that many eggs into a binary file is dangerous. (or
>>a needless risk at any rate)... ONE little goofup and you can't fix it.
>
>He didn't say, 'Make an API to a cryptic binary file', he said make an
>API.
Correct. When I said "without having to worry about Physical
Representation," that specifically *denies* there being any claim to a
particular representation.
I did not say that there would be "a cryptic binary file." I also did
not say that there would not be one, but if you read any of the rest, it
should be pretty clear that I am *NOT* promoting the use of "a cryptic
binary file."
>One thing that he didn't say in his response (least, if he did, I missed
>it), is that with so many programs using this data, and possibly
>changing this data, it would be good to have an API so that you have one
>program that handles write access to the file properly. That is, if it
>needs to write to the file, everyone gets put on hold while it does so.
I didn't say anything about it, but that is certainly a fair comment.
It surely would be nice for an API to manage "physical" locking for you.
>Another way of putting what he's saying - 'Make a vipw, rather than edit
>/etc/passwd directly.' Sure, vipw's pretty much useless on a
>single-user machine. But in an environment with 20 system
>administrators, where any of them can edit /etc/passwd, vipw suddenly
>makes a lot more sense. Of course, since you've also got the new guys
>in there, adduser makes more sense. Oh, my, greater API complexity.
vipw would be an example of an implementation of the locking side of
this.
It doesn't handle either:
a) Reading values based on some key, or
b) Updating values based on some key,
so while it represents a nice example of a "locking abstraction," it
*doesn't* provide read/write capabilities per se.
It's worth looking at when figuring out how to lock files.
>>Two, putting all the configuration stuff into one file makes changes on fly
>>trickier than it need be. Why do you think windows needs to reboot so damn
>>much? I'd have to guess because it's the only way MS can ensure that
>>registry changes get "read" into all the apps.
>
>You really think that we can't have our API reload the file without
>rebooting? Bah.
And this assumes that the configuration is stuffed into one file. That
certainly assumes something that I did not say.
>>Two (cont), if you have a constantly changing registry, do you ask that the
>>APPS re-read it every now and then to make sure that they are using the most
>>up to date info? Wouldn't this require a whole new CALLBACK type of
>
>No more than you have them re-read the configuration files they already
>have. *Their* information will not change any more rapidly; it's just
>that all the changes happen close to the same spot now.
Synchronizing updates is indeed one of the issues that needs to be
resolved.
Many UNIX daemons handle this via "kill -SIGHUP"; when the daemon
receives an appropriate signal, it rereads its configuration. That
works fairly well; it wouldn't be a bad thing to have another "commonly
usable" way to, as it were, give a "swift, sharp kick" to indicate that
there is new config information.
>>function ? If apps (and/or the OS) started depending on a registry,
>>wouldn't that registry have to ALWAYS have the latest data? How would you
>>ensure this? Call a kill -HUP on EVERY program that uses it to ensure the
>
>Each time it handles a response, if it's more than <configurable time>
>since it last read the configuration file, it checks the mod timestamp.
kill -SIGHUP has the advantage that it doesn't "kick" the service until
*all* updates are done.
It is preferable to wait 'til the work is done.
--
if (argc > 1 && strcmp(argv[1], "-advice") == 0) {
printf("Don't Panic!\n");
exit(42);
}
(Arnold Robbins in the LJ of February '95, describing RCS)
[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
******************************
