Linux-Development-Sys Digest #318, Volume #6 Fri, 22 Jan 99 12:14:01 EST
Contents:
Re: disheartened gnome developer (Christopher B. Browne)
Re: INT13 disk driver (Andreas Mohr)
Re: PROPOSAL: comp.unix.year-2038 (WAS: 2038 and Linux) (Christopher B. Browne)
Re: Newbie question - interrupt handler trouble (Gordon Scott)
Re: Can I run a DOS Device Driver in an emulator (David Steuber)
Re: PROPOSAL: comp.unix.year-2038 (WAS: 2038 and Linux) (Bloody Viking)
Re: Newbie Question (JiPUSTRADAMUS)
Error in un.h ? (Frank Kehren)
Re: PROPOSAL: comp.unix.year-2038 (WAS: 2038 and Linux) (Andreas Schwab)
Kernel 2.2.0-pre9 VFAT bug ("Jan Matejka")
Re: Newbie Question (Dirk Nuyens)
----------------------------------------------------------------------------
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: Thu, 21 Jan 1999 06:17:41 GMT
On 20 Jan 1999 14:20:27 -0800, Michael Powe <[EMAIL PROTECTED]>
posted:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>>>>>> "Bob" == "Bob Taylor" <[EMAIL PROTECTED]> writes:
>
> Bob> Please define what *you* mean by "free market".
>
>Doh! A market in which all decisions are rational. (Note that I do not
>endorse this idea as a ruling theme of one's life, I'm merely giving a
>definition.)
When people don't make all decisions on rational bases, it's not realistic
to expect this "pure" thing to ever exist.
I find it a bit strange that you seem to be treating "free" and "rational"
synonymously.
I would instead regard "free" as indicating that, generally speaking,
decision makers in the market are "not coerced," and more particularly, have
a maximum of "degrees of freedom" (in the mathematical sense).
In a market where there is either a choice of buying what's there or going
home empty-handed (which may describe either the old style Soviet bread
lines, or computer stores that offer only "Intel Inside" and "Microsoft
Inside"), there is relatively little freedom, offering only a very limited
scope of choice. Few degrees of freedom.
A freer market will offer a multiplicity of products, with an assortment of
potential substitutions. This increases the "degrees of freedom," and is
*freer.*
Ultimate freedom would require having an infinite spectrum of choices.
Since many real things are measured in discrete portions, this prevents that
from being attained even in theory.
In practice, having some "reasonable amount of freedom of choice" represents
a market that is "free enough" for most purposes.
--
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] (Andreas Mohr)
Subject: Re: INT13 disk driver
Date: 22 Jan 1999 10:25:56 GMT
Frank T. Lofaro ([EMAIL PROTECTED]) wrote:
> In <787hdc$u2g$[EMAIL PROTECTED]> on 21 Jan 1999 07:34:04
-0800, Tim Smith <[EMAIL PROTECTED]> wrote in comp.os.linux.development.system:
> >Villy Kruse <[EMAIL PROTECTED]> wrote:
> >>For real non-standard stuff you are really on your own. The INT13
interface
> >>cannot be used as it needs to run in old 8088 mode wheras linux needs to
run
> >>in real 80386 aka protected mode.
> >This is incorrect. A protected mode operating system can make use of
> >INT 13h by creating a V86 mode task to make the INT 13h calls. OS/2
> >does this if it doesn't have a protected mode driver for your disk
> >controller, for example.
> >--Tim Smith
> Firstly, I'd hate to see Linux turn into DOS...
hehe ;-)
> Anyway, you are right, you can call a real mode INT from VM86 mode,
> BUT:
> 1. INT 13h has to point to where it needs to be. Linux revectors the
> INTs. You'd need to know where it pointed and use a different INT
> (I believe 13h to be taken for processor exceptions, etc) or change
> and restore it.
Well, that functionality of remembering the original BIOS vector
could be implemented into Linux if needed...
> 2. Did it point into a BIOS routine or a TSR? TSRs require DOS, or
> some of its services to function. Having the kernel call DOSEMU is
> UGLY!
I think it only makes sense to call BIOS Int 13h support for special storage
devices.
I certainly don't believe TSR/.sys int 13h extension support would be
A Good Thing.
Those things would be traceable through DOSEMU anyway.
So using the trace log you could just write a Linux driver instead...
> 3. Does it need to make IO calls? Yes it does it your case (IDE
> driver). Need to give it IOPERMS. Risk to system integrity due to
> bugs in driver you have no source to, which wasn't designed to run
> from VM86 mode in a protected mode OS, and which might take actions
> that conflict with Linux's access to devices (e.g. it tries also
> accessing hardware Linux uses, such as DMA page registers).
Exactly !
But that could be solved by calling another Linux kernel driver that
will be needed for Wine DMA/IRQ access soon
(Windoze 16bit hand scanner drivers etc.).
That way you could have _emulated_ DMA access by trapping DMA ioport access,
which would lead to perfect Linux DMA cooperation.
Of course this kernel driver would be loaded only if really needed.
> 4. VM86 is not real mode. Some things a program does WILL have
> different effects, and these things do not cause a trap, so the OS
> can't fix it. Case in point, "unauthorized" attempts to set
> processor state bits (IOPL, protection ring, MSRs, etc) are
> silently dropped. The OS can't fix it. The driver might crash as a
> result. Sure, we'll get a trap when the driver does an unauthorized
> operation, but do we know if the driver tried to set its IOPL, etc?
> No, since the request was dropped. This might have changed with the
> Pentium extended VM86 bits. Or not.
> This sounds like a bad situation.
Yep, BUT that would be a driver for situations where anything else completely
fails...
I wouldn't intend/recommend to use such a driver in a router/gateway/file
server anyway ;-))
--
Andreas Mohr
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To:
comp.os.linux.misc,comp.os.linux.advocacy,comp.software.year-2000,comp.unix.advocacy
Subject: Re: PROPOSAL: comp.unix.year-2038 (WAS: 2038 and Linux)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 21 Jan 1999 06:17:46 GMT
On 21 Jan 1999 01:34:52 GMT, Bloody Viking <[EMAIL PROTECTED]> posted:
>In comp.os.linux.advocacy Christopher B. Browne <[EMAIL PROTECTED]> wrote:
>
>: It is still necessary to make source code changes to cope with this. It's
>: obviously necessary to specify the new form of time_t.
>
>It's not hard to rummage in the kernel source to find the time_t
>definition.
True.
>: Furthermore, it will be necessary either to add to ext2fs some sort of
>: "date signature" so that the date format may be detected, so we can correctly
>: determine if a particular filesystem uses 32 or 64 bit dates, or perhaps to
>: define the "2038-compliant" version as ext3fs. After all, the day that
>: the kernel that "does dates right" is released, there will still be a lot of
>: "legacy" filesystems that have the present functionality.
>
>Ouch. That's a hack. So, with the ext2fs shit left over, you'd need a hack
>to access it or preferably put it onto the ext3fs then reformat the ext2fs
>partitions to ext3fs partitions, then untasr the files back in place.
>
>Given how all this is more complicated than I can handle, I personally
>might be better off with the backdate hacks. A good thing is that we are
>talking about this NOW, instead of waiting until the last minutes like
>Y2K.
I'd probably use CPIO to do the job, but close enough...
It would indeed prove necessary to have *some* "hackery" to deal with the
legacy filesystem. I would suggest that it's far less of a big deal to
handle "ext3fs is 2038 compliant, and ext2fs isn't" than it is to hack on
backdating things, which is something that will *never* leave you alone.
If you take the ext2fs data and move it to ext3fs, then the job is done, and
so long as you don't create any "old" fses, you never need worry again.
Having explicit hacks are forever...
>The Y2K debacle is the precedent for Y2038.
Nope.
The Y2K debacle is a clear example of how thoughtless system design gets
people in trouble in arbitrarily stupid ways.
That's *not* the case with the UNIX 2038 problem. It was anticipated long
ago, and there *are* remediation methods that aren't anywhere *near* as
horrible as what the Y2K folks are working with.
--
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] (Gordon Scott)
Subject: Re: Newbie question - interrupt handler trouble
Date: 22 Jan 1999 09:36:36 GMT
Reply-To: Gordon Scott <[EMAIL PROTECTED]>
I'd go along with checking that i is wat you think it is, and I
think I'd wrap the #defined stuff in () so it doesn't risk breaking
something else (I can't see a cause for you problem there though).
If any of the stuff in the for() loop is a macro, check also for
unexpected side-effects there.
Your cut-down example *does* have a bug:
Alex Bolenok ([EMAIL PROTECTED]) wrote:
: Mark Tranchant wrote in message <[EMAIL PROTECTED]>...
: if (flag = 0xC0)
^ Oops!
G.
--
Gordon Scott Opinions expressed are my own.
[EMAIL PROTECTED] (official) [EMAIL PROTECTED] (backdoor)
[EMAIL PROTECTED] (home) http://www.apis.demon.co.uk
Linux ............... Because I like to _get_ there today.
------------------------------
From: David Steuber <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development,comp.os.linux.hardware,comp.os.linux.misc
Subject: Re: Can I run a DOS Device Driver in an emulator
Date: 21 Jan 1999 22:00:11 -0500
"Norm Dresner" <[EMAIL PROTECTED]> writes:
-> I have a special video card that needs to be initialized by a DOS device
-> driver. There's nothing else available (unless you count windoze). (For
-> the curious, it's a Targa+ overlay card.)
->
-> All suggestions, hints, and even sympathy, gratefully accepted.
I don't know if there are any worthy replacements that are Linux
compatible, but you could look into that.
I wonder if there is already a Linux driver for that card?
--
David Steuber
http://www.david-steuber.com
s/trashcan/david/ to reply by mail
SYSTEM ALERT: /dev/null is full. Please delete any unnecessary files.
------------------------------
From: Bloody Viking <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.misc,comp.os.linux.advocacy,comp.software.year-2000,comp.unix.advocacy
Subject: Re: PROPOSAL: comp.unix.year-2038 (WAS: 2038 and Linux)
Date: 21 Jan 1999 07:08:07 GMT
In comp.os.linux.development.system Christopher B. Browne <[EMAIL PROTECTED]>
wrote:
: On 21 Jan 1999 01:34:52 GMT, Bloody Viking <[EMAIL PROTECTED]> posted:
:>It's not hard to rummage in the kernel source to find the time_t
:>definition.
: True.
I'm no expert but I was able to find time_t.
: It would indeed prove necessary to have *some* "hackery" to deal with the
: legacy filesystem. I would suggest that it's far less of a big deal to
: handle "ext3fs is 2038 compliant, and ext2fs isn't" than it is to hack on
: backdating things, which is something that will *never* leave you alone.
Yeah, before the time_t expiry, you tar up the ext2fs partitions, move the
tars, then format the ext2fs partitions into ext3fs, and untar right back.
: If you take the ext2fs data and move it to ext3fs, then the job is done, and
: so long as you don't create any "old" fses, you never need worry again.
Yep. You use tar. Nice and clean. A fun issue is after this with Y2K+38,
by that time, programmers will revert to the old 2 digit habit so as to
make Y2.1K.
: Having explicit hacks are forever...
Or bloody close to forever! :) RTCs of PCs aside, the 64 bit time_t is
good to go for QUITE a while. 4-digit-year apps will be good for
kiloyears... until Y10K, of course!
: The Y2K debacle is a clear example of how thoughtless system design gets
: people in trouble in arbitrarily stupid ways.
Not to mention bean counters pinching pennies telling coders how to code.
: That's *not* the case with the UNIX 2038 problem. It was anticipated long
: ago, and there *are* remediation methods that aren't anywhere *near* as
: horrible as what the Y2K folks are working with.
The Y2K debacle is that of app code being a needle in a haystack. Is there
a remediation package for Linux yet? I sure wouldn't want to be Dave
onboard the USS Discovery with a Linux HAL9000 in 2038 that wasn't
remediated! :)
"Open the pod bay door, Hal."
"I'm sorry, Dave, but the mission wasn't started. My memory banks says
it's 1970."
"What are you talking about, Hal?"
"It's January first, 1970. The movie about us wasn't even released about
us, Dave. Goodby."
<Dave drives off into the monolith, acceelerates to lightspeed, and drops
some acid...>
--
CAUTION: Email Spam Killer in use. Leave this line in your reply! 152680
T-minus 344 Days, 23 Hours, and 1 Minutes until Y2K and counting.
3434298 bytes of spam mail deleted. http://www.wwa.com/~nospam/
------------------------------
From: JiPUSTRADAMUS <[EMAIL PROTECTED]>
Crossposted-To:
alt.uu.comp.os.linux.questions,comp.os.linux.hardware,comp.os.linux.misc
Subject: Re: Newbie Question
Date: Fri, 22 Jan 1999 13:31:22 +0200
On Thu, 21 Jan 1999, Charles Riley wrote:
> Is there any way to access a Zip Drive from Linux? Please help ASAP!!! I
> need to copy over my newest video drivers from a WIN98 partition, but they
> are too big and I'm not sure any other way....
Can't help you with the zip-drive, but if your drivers are on the same drive
as your linux is, then copying them over is no big deal... Just mount the
windows '98 partition, and you'll be able to access all files on that
partition... /Check man mount for details, if you are unsure about mounting)
JP
------------------------------
From: Frank Kehren <[EMAIL PROTECTED]>
Subject: Error in un.h ?
Date: Fri, 22 Jan 1999 13:53:17 +0100
Hello,
my Compiler (pgcc-2.91.51 on Pentium) complains when including the file
un.h from the linux kernel (/usr/src/linux/include/linux/un.h,
SuSE-Kernel 2.0.36),
that "ANSI C++ forbids zero-size array `cmsg_data'".
Does anybody know, why they use an array with length 0 ?
Thanks, Frank
--
Frank Kehren
[EMAIL PROTECTED]
------------------------------
From: Andreas Schwab <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.misc,comp.os.linux.advocacy,comp.software.year-2000,comp.unix.advocacy
Subject: Re: PROPOSAL: comp.unix.year-2038 (WAS: 2038 and Linux)
Date: 22 Jan 1999 13:56:00 +0100
Andre Fachat <[EMAIL PROTECTED]> writes:
|> In comp.os.linux.development.system Bloody Viking <[EMAIL PROTECTED]> wrote:
|>
|> > Yeah, before the time_t expiry, you tar up the ext2fs partitions, move the
|> > tars, then format the ext2fs partitions into ext3fs, and untar right back.
|>
|> I'm no expert, but how does tar save the dates of a file?
As an octal ascii string, like all other numbers in the header.
--
Andreas Schwab "And now for something
[EMAIL PROTECTED] completely different"
[EMAIL PROTECTED]
------------------------------
From: "Jan Matejka" <[EMAIL PROTECTED]>
Subject: Kernel 2.2.0-pre9 VFAT bug
Date: Fri, 22 Jan 1999 16:40:40 +0100
Hi,
in kernel 2.2.0-pre9 when I try to move file _within_ DOS
FAT16 or FAT32 partition, I always receive error:
file not found
Moving files between _different_ DOS partitions works OK.
in kernel 2.2.0-pre8 the same situation typically ended with
system crash: NULL pointer inside kernel
I am using Slackware 3.6 and gcc 2.7.2.3, all partitions
are on SCSI disk connected to Adaptec 2940.
Matej
------------------------------
From: Dirk Nuyens <[EMAIL PROTECTED]>
Crossposted-To:
alt.uu.comp.os.linux.questions,comp.os.linux.hardware,comp.os.linux.misc
Subject: Re: Newbie Question
Date: Fri, 22 Jan 1999 17:22:58 +0100
==============851DD2F6BB3EB4251DD32335
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Charles Riley wrote:
> Is there any way to access a Zip Drive from Linux? Please help ASAP!!! I
> need to copy over my newest video drivers from a WIN98 partition, but they
> are too big and I'm not sure any other way....
>
> I can't get my modem to work in Linux...(I just started installing today...)
>
> Chip Riley
is this an internal ATAPI zip drive? then follow these steps (and hope that you
have support for ATAP floppy in your kernel: SuSE and RH have)
$ mkdir /mnt/zip # so
you have a directory to mount it on
$ mount -t vfat /dev/hdd4 /mnt/zip # the type of your
zip floppy will probably be vfat (win95)
# the only thing you should figure out is where your zip is eg /dev/hdd4,
/dev/hdb4, /dev/hdc4
if the mount fails you should try the other possible devices, but it's always
the 4th partition
after that you can simply cd to the mounted directory and do your thing
mounting your windows is the same proces... you should now where your windows
partition is eg /dev/hda1 (probably)
$ mkdir /mnt/dos
$ mount -t vfat /dev/hda1 /mnt/dos
anyway check out "man mount" and read something about /etc/fstab for automic
mounting of your dos thing
when done with your zip you will notice that you can't eject it, that's because
it is still mounted, do the following:
$ cd / #
go away from the drive, don't use it by sitting there
$ umount /mnt/zip # notice
that it's umount not unmount
hope this helps....
--
Dirk Nuyens
==============851DD2F6BB3EB4251DD32335
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
Charles Riley wrote:
<BLOCKQUOTE TYPE=CITE>Is there any way to access a Zip Drive from Linux?
Please help ASAP!!! I
<BR>need to copy over my newest video drivers from a WIN98 partition, but
they
<BR>are too big and I'm not sure any other way....
<P>I can't get my modem to work in Linux...(I just started installing today...)
<P>Chip Riley</BLOCKQUOTE>
is this an internal ATAPI zip drive? then follow these steps (and
hope that you have support for ATAP floppy in your kernel: SuSE and
RH have)
<BR> $ mkdir
/mnt/zip
# so you have a directory to mount it on
<BR> $ mount -t vfat /dev/hdd4
/mnt/zip
# the type of your zip floppy will probably be vfat (win95)
<BR>
# the only thing you should figure out is where your zip is eg /dev/hdd4,
/dev/hdb4, /dev/hdc4
<BR>if the mount fails you should try the other possible devices, but it's
always the 4th partition
<BR>after that you can simply cd to the mounted directory and do your thing
<BR>mounting your windows is the same proces... you should now where your
windows partition is eg /dev/hda1 (probably)
<BR> $ mkdir /mnt/dos
<BR> $ mount -t vfat /dev/hda1 /mnt/dos
<P>anyway check out "man mount" and read something about /etc/fstab for
automic mounting of your dos thing
<P>when done with your zip you will notice that you can't eject it, that's
because it is still mounted, do the following:
<BR> $ cd
/
# go away from the drive, don't use it by sitting there
<BR> $ umount
/mnt/zip
# notice that it's umount not unmount
<P>hope this helps....
<PRE>--
Dirk Nuyens
<[EMAIL PROTECTED]></PRE>
</HTML>
==============851DD2F6BB3EB4251DD32335==
------------------------------
** 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
******************************
