Linux-Development-Sys Digest #952, Volume #6 Mon, 12 Jul 99 19:13:58 EDT
Contents:
SkyOS ("Szeleney Robert")
Debugging with NMI (David Grothe)
ADULTS ONLY! 33726 ([EMAIL PROTECTED])
micro kernel (Olivier Scalbert)
Help: Kernel file I/O (Mike Harrison)
Re: New OS development (Rafael The X-Slasher)
embedded linux in a specific application... (William Ryder)
Re: Debugging with NMI (Emile van bergen)
pci driver/insmod ("Linda Singer")
Re: NT to Linux port questions (Emile van bergen)
Project problem - linux printer port ("smith")
Re: CD-ROM File Time Bug ("Charles Sullivan")
----------------------------------------------------------------------------
From: "Szeleney Robert" <[EMAIL PROTECTED]>
Subject: SkyOS
Date: Mon, 12 Jul 1999 18:57:01 +0200
Hi!!!
SkyOS Server is up again!!!
Take a look at http://skyos.ics.at
Current Status of the OS:
32-Bit Protected Mode
Paging
Multitasking (only ring 0 kernel tasks)
Exception Handling
Relocated Stack Area
1024x768 SVGA GUI with 256 colors
SVGA Card check in Text-Mode
Memory Management (up to 4 GB allocateable)
Virtual Filesystem
SKY Filesystem (readonly)
Keyboard Device Driver (german layout)
Floppy Device Driver
IDE Device Driver
Ramdisk Device Driver
Mouse Device Driver (mc, serial)
SVGA Windows 95 Look GUI (clipping, window handling)
3Com Etherlink III 3c509 Ethernet Card Device Driver
VESA 2.0 SVGA Device Driver
Trident 8800/9400/9660 SVGA Device Driver (up to 2 MB RAM)
Protocol Manager
Network Support (ARP, IP, ICMP, UDP, TCP Protocol)
FTP client (some troubles)
Device Manager
Help Task
System Monitor
Memory Monitor
Process Monitor
Palette Viewer
Buttons, Edit fields
Static Text
Menus
WinInfo - Task
Memory Manager Tasks (debug page tables, memory, ....)
Taskmanager (Create new tasks, modifiy their registers, ....)
Image Viewer
Task Bar
VESA Linear Frame Buffering
Virtual Device manager (C++ Module)
Standard extern Modem support (alpha alpha version)
Terminal programm (alpha alpha version)
Cu, Bertl!!!
------------------------------
From: David Grothe <[EMAIL PROTECTED]>
Crossposted-To: revue.linux-kernel
Subject: Debugging with NMI
Date: 12 Jul 1999 19:35:39 +0200
Reply-To: [EMAIL PROTECTED]
Kernel hackers:
Maybe this is old hat, but it is new to me --
On an ISA bus machine, if you short out the A1 and B1 pins of an ISA
slot you will generate an NMI to the CPU. This interrupts even a
machine that is hung in a loop with interrupts disabled. Used in
conjunction with kgdb <
ftp://ftp.gcom.com/pub/linux/src/kgdb-2.2.6/kgdb-2.2.6.tgz > you can
gain debugger control of a machine that is hung in the kernel! Even
without kgdb the kernel will print a stack trace so you can find out
where it was hung.
The A1/B1 pins are directly opposite one another and the farthest pins
towards the bracket end of the ISA bus socket. You can stick a paper
clip or multi-meter probe between them to short them out.
I had a spare ISA bus to PC104 bus adapter around. The PC104 end of the
board consists of two rows of wire wrap pins. So I wired a push button
between the A1/B1 pins and now have an ISA board that I can stick into
any ISA bus slot for debugger entry.
Microsoft has a circuit diagram of a PCI card at
http://www.microsoft.com/hwdev/DEBUGGING/DMPSW.HTM. If you want to
build one you will have to mail them and ask for the PAL equations.
Nobody makes one comercially.
[THIS TIP COMES WITH NO WARRANTY WHATSOEVER. It works for me, but if
your machine catches fire, it is your problem, not mine.]
-- Dave (the kgdb guy)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.hardware,comp.os.linux.m68k
Subject: ADULTS ONLY! 33726
Reply-To: [EMAIL PROTECTED]
Date: Monday, 12 Jul 1999 11:48:30 -0600
This is for Adults Only:
http://207.240.225.250
* 18+ Only Please!
.
7,LFmRdng"
------------------------------
From: Olivier Scalbert <[EMAIL PROTECTED]>
Subject: micro kernel
Date: Mon, 12 Jul 1999 20:39:13 +0200
Hello,
I would like to build a very little micro-kernel (pico kernel ?) on PC,
just for an educational point of view.
I would like to develop it on a Linux box, produce a bootable floppy and
boot it on an other PC. I have few questions:
How can I write a sector on a floppy ?
How can I produce non relocatable code ?
C, C++ compilers: which one to use ?
Thanks in advance.
Olivier Scalbert
------------------------------
From: [EMAIL PROTECTED] (Mike Harrison)
Subject: Help: Kernel file I/O
Date: 12 Jul 1999 21:02:52 GMT
Can someone with kernel programming experiance tell me what is going on
here?
I have a function that is supposed to collect data in the kernel then
write it out to a file periodically. I am having trouble with opening the
file.
I am using "fd = open("/var/log/kw",O_WRONLY|O_CREAT,644);" to open the
file then using write(...) to put data out there and close(fd) to close
it. Pretty straight forward, right? Well, the first time the file open
and closes fine with the data out there but any subsequent tries result in
a file open error(errno = 14 I think). What am I doing wrong here?
thanks.
michael harrison
------------------------------
From: Rafael The X-Slasher <[EMAIL PROTECTED]>
Subject: Re: New OS development
Date: Mon, 12 Jul 1999 20:58:57 GMT
Cool !! What are your main goals ? I mean, do you want to make it "user-
friendly" or what ?
--
Rafael "The X-Slasher" Pereira
ICQ# 12758282
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: William Ryder <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,comp.os.linux.misc
Subject: embedded linux in a specific application...
Date: Mon, 12 Jul 1999 17:26:26 -0400
First, thanks to all those who responded to my question about I2O
wrappers in a Linux RTOS environment. We've kind of decided we might
end up writing I2O support for ourselves, so now the question we have
boils down to the following...
As a refresher, I work for a group considering Linux in an embedded
application using a MIPS processor and a Galileo support chip. We are
defining embedded as meaning "diskless, file system-less, and bootable
from prom." Topics under discussion on our end include:
-is Linux available for such an application, that is, are there real
Linux kernels and sources available right now?
-are there development tools available?
-are there companies that might be able to aid us in development of
kernel specific and/or application code?
-for each affirmative answer, where specifically can we go to find what
we need?
So far I've only been able to dig up bits and pieces while we really
need a more comprehensive answer. As things are going I think we can
contribute several things to the Linux community out of the project we
are working on but I've got to convince management that Linux is the way
to go first.
Any help will be very appreciated, and again, thanks to all those who
responded to my first e-mail; the answers provided really helped!
Thanks,
Bill Ryder
Unisys Corporation
Malvern, PA.
------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Subject: Re: Debugging with NMI
Date: Mon, 12 Jul 1999 23:50:24 +0200
On Mon, 12 Jul 1999, David Grothe wrote:
>Kernel hackers:
>
>Maybe this is old hat, but it is new to me --
>
>On an ISA bus machine, if you short out the A1 and B1 pins of an ISA
>slot you will generate an NMI to the CPU. This interrupts even a
>machine that is hung in a loop with interrupts disabled.
[SNIP]
Grin... exactly the same thing I found out and used in my own 386 (real
mode) monitor that I wrote and used to hack DOS games when I was a
teenager...! The monitor could even be used over a serial port, to
prevent screen corruption while in graphics mode... ;-) If anyone would
be interested to use for something else, grab it at
ftp://n293.ede.telekabel.euronet.nl/pub/evb/monitor. It has a syntax
similar to the old 'debug.exe', but does a _complete and correct_
disassembly of all 386 instructions, assuming 16 or 32 bit code segments
(no 387 though, and the syntax is the intel one, not AT&T), and takes
advantage of hardware breakpoints on instruction fetch, memory access
etc.
Today, its use is probably limited, because it offers no protected mode
support, but hey, the disassembly module is still good and could be
reused I guess... ;-)
--
M.vr.gr. / Best regards,
Emile van Bergen (e-mail address: [EMAIL PROTECTED])
This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
~
~
:wq
------------------------------
From: "Linda Singer" <[EMAIL PROTECTED]>
Subject: pci driver/insmod
Date: Mon, 12 Jul 1999 17:44:26 -0400
I'm beginning a driver (module) for a pci device with a simple skeleton to
interface with the pci config regs on the device.
After compilation doing insmod -o module_name.o
give unresolved symbol of ioremap.
Sure enough ksyms show no ioremap...
question is why and how do I get it mapped/linked in?
thanks
Matt Singer
[EMAIL PROTECTED]
------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Subject: Re: NT to Linux port questions
Date: Mon, 12 Jul 1999 23:41:02 +0200
On Mon, 12 Jul 1999, Matthew Carl Schumaker wrote:
>Tryimg uluate the WaitForMultipleObjects under LInux is terrible at
>best(speaking from experience) the fact is that Linux/Unix and Windows
>take two d different approaches to system apps. MS prefers events and
>asynchronous stuff,(read the MSDN files about using the POSIX calls for
>sockets that block, they say to use the WSA stuff instead)
>while Linux/Unix prefers blocking calls. THe closest
>things to MS Events under Linux are pthread signals but you can't wait 2+
>simultaneous signals as in the WaitForMultipleObjects(fWaitAll = true).
>System signals are poor replacements for MS Events since there are only 2
>user defined signals and the majority of the other signals are meant to
>kill the app. As for handles, They are supposed to be completely unique
>and thus require some sort of routine(I think MS uses a combination of
>hardware address(like MAC from the NIC) and time and date and a heafty
>dose of black magic, But I'm not too sure about this)
This story sounds like complete bogus to me. Sorry to be harsh, but I
seriously think that you should read up on how Unix does things instead
of 'finding the Linux equivalent to'. And even if you were about to do
that, you could have done a better job.
In unix, the 'objects' are called files. A process can have a handle to
an open 'file'. It can be a (tcp/udp/unix) socket, a fifo, a terminal, a
file, a sound card, whatever. It is, indeed, kind of an object.
Unix also has the ability to wait for something to happen on an object
(e.g. it becoming ready to be read, i.e. 'data available', or ready to
be written to (output empty), or some out-of-band event), and that
ability is called select(). Read its man page, please. You _don't_ have
to use blocking reads and then multithreading to overcome it!!
Signals, otoh, are completely asynchronous and could occur anywhere in
your program. Sort of like 'system interrupts' as opposed to
hardware interrupts. Each one can be handled by a routine (signal
handler) that you can attach to it.
So use select() if you want to wait until _anything_ happens
that has something to do with I/O (including a timeout), and then
continue the flow of execution in the same routine. It is indeed very
similar to some 'wait_for_multiple_objects' routine, because that's
exactly what it does...! That's why I said you could have done a better
job finding your equivalent.
And if you absolutely insist on turning your program into spaghetti
using callbacks all over the place, why not create a tiny select loop
with a routine dispatcher in it for each filedescriptor that may become
ready? Then you have the same mess you're probably used to.
Use signals for asynchronous handling of catastrophes, or things that
are almost completely isolated from the rest of the program (think when
you would use an interrupt handler in DOS). Otherwise, where to record
state? In some static global variables? Your app would turn into a mess
very quickly, I guess.
You could also create a fifo, have all signal handlers do nothing except
write the signal number into it, and include the reading end of the fifo
in your select loop. Voila, a message dispatch system using _one_
routine (select()) for really (and I mean really) _all_ events that can
possibly occur on a Unix system (except events like lightnings, power
outage and such, of course ;-).
Event driven programming may be nice in some aspects of implementing a
GUI, but the thought of designing a complete application that way makes
me shiver. Oh wait, VB/VC++ actually _encourages_ to design your app
around the gui parts. Guess I almost forgot about that. Never mind ;-)
--
M.vr.gr. / Best regards,
Emile van Bergen (e-mail address: [EMAIL PROTECTED])
This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
~
~
:wq
------------------------------
From: "smith" <[EMAIL PROTECTED]>
Subject: Project problem - linux printer port
Date: Sun, 11 Jul 1999 23:05:55 -0700
Project problem - linux printer port
I am trying to wire a simple video switch to the parallel port of a PC and
have Linux
it.
So far I have made a connector that fools linux into beleiving that it has a
printer
connected, and have sent data to it.
However I dont seem to be able to get the results I expect.
Im using "echo -ne '\361' >/dev/lp0" to output the byte.
I would expect results like this :
28 64 32 16 8 4 2 1 dec oct
1 1 1 1 1 = 1 (241) 361
1 1 1 1 1 = 2 (242) 362
1 1 1 1 1 = 3 (244) 346
1 1 1 1 1 = 4 (248) 370
What i'm getting is very confusing.........
Does anyone know if a) the LP device is trying to do CRLF expansion ?
or b) a simple working utility to output a byte to the data latch on
parallel port ???
I'm using RedHat 6 on a Pentium.
Any help apreciated, please email me - thanks
[EMAIL PROTECTED]
------------------------------
From: "Charles Sullivan" <[EMAIL PROTECTED]>
Subject: Re: CD-ROM File Time Bug
Date: Mon, 12 Jul 1999 17:33:28 -0400
This is a multi-part message in MIME format.
=======_NextPart_000_0038_01BECC8C.A768BEE0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I think I've figured out the problem, for DOS floppies and other
VFAT file systems at least: =20
When the system is set to a "dual" time zone like EST5EDT and
when creating or copying to a VFAT file system, Linux uses only
the second time zone, i.e., EDT, regardless of the system date
or file date. However it compensates when reading back the
files from VFAT to Linux. Example: Two files are created in
Linux (ext2), with the system configured so that clock and local
time zone are both UTC0, one in January and one in July, but=20
both with time 7:00 AM UTC. If the system is then reconfigured
with both clock and timezone set to EST5EDT, 'ls' displays the
(ext2) file times correctly in local time, i.e., Jan =3D 2:00 AM (EST)
and Jul =3D 3:00 AM (EDT). If both files are then copied to VFAT floppy
(or HDD or ZIP), the files times are both written as 3:00 AM and
displayed as such by either DOS or mdir. (Linux compensates and
'ls' on the floppy displays the correct 2:00 AM or 3:00 AM).
This looks like a bug to me.
Regarding the CDROM, I've observed that with clock and local time
set to UTC0, the time displayed for a file is identical to that
for the same file copied to a VFAT file system, so either the
ISO9660 file system stores file times in UTC or Linux assumes it
does. In either case, the file times when displayed by 'ls' in
EST5EDT have the correct offsets from UCT0.
Regards,
Charles Sullivan=20
PS: Sorry about the proportional font in my original message.
Peter Samuelson wrote in message <7m9agu$uqs$[EMAIL PROTECTED]>...
>[Charles Sullivan <[EMAIL PROTECTED]>]
>> Can someone explain what's going on here?
>
>Hmmm, I can try.
>
>> Under MS-DOS (Win 98) I copied two files from a CD to my hard drive,
>> to a floppy disk, and to a ZIP disk. One file has a create date in
>> January, the other in July.
>
>So after you copied them, are the dates *still* January and July?
>I.e. did DOS preserve the CD timestamps or write new ones? I'm just
>making sure you're seeing what you think you're seeing. I don't have
>access to an MS-DOS machine (thank goodness) but Windows NT 4 seems to
>be preserving timestamps on floppies.
>
>> I am in the Eastern US time zone. My system clock is presently set
>> to today's date (10 July 1999) and time, which is Eastern Daylight
>> Time.
>
>Meaning what? Normally the system (kernel) clock is set in UTC, and
>the hardware clock is too. For dual-boot compatibility with legacy
>systems, some distributions offer the option of putting the hardware
>clock in local time and correcting the kernel clock via a boot script.
>
>The time *you* see is governed by either your TZ variable or the libc
>default, which is the contents of /etc/timezone. `ls' converts kernel
>time using this.
>
>> here's what I get for the time. (This is the hour only
>[...]
>> File MS-DOS Linux=3D> CDROM HDD Floppy ZIP
>> ---- ------ ------------- --- ------ ---
>> Jan 22 17 21 21 21
>> July 12 8 12 12 12
>
>I presumed to "correct" for what looks like proportional spacing in
>your editor. (For shame!) In fixed spacing, is the above correct?
>
>> If I reset my hardware clock to a date in January and reboot Linux,
>> the 'date' command reports the date I have set, denoted 'EST'. But
>> the file times in the various media reported by ls are identical to
>> those shown above.
>
>Yes. The timestamps are the same. And you didn't change your
>timezone, so they will be presented the same way. You seem to be
>expecting that if you're in EDT, a January file will be listed in EDT.
>Not so -- it was created during non-daylight time, so is listed in EST.
>Similarly, a July file is listed in EDT, since July is during daylight
>savings. Thus the "reported" time will be the same year-round,
>assuming the file timestamp isn't touched.
>
>> It looks like Linux is assuming that the CD file are UTC and is
>> figuring that out from the DOS date (assumed to be Eastern time). Is
>> this correct?
>
>Yes except substitute "libc timezone" for "DOS date". Linux assumes
>the CD was mastered (actually that the ISO9660 filesystem was created)
>in UTC. So a January file is reported 5 hours behind its actual
>timestamp, a July file 4 hours behind.
>
>In my limited testing here, it looks like mtools doesn't do any
>timezone correction (hey, it's trying to be as much like MS-DOS as
>possible so I guess it really shouldn't), but of course regular system
>utilities (like GNU fileutils) do.
>
>> I don't understand why the difference of one hour in the January file =
on
>> the other media.
>
>Not sure about that part. Rerun your test, if you will, after typing
>
> export TZ=3DUTC0
>
>into your shell. That makes `ls' tell you exactly what times the
>kernel gives it.
>
>--=20
>Peter Samuelson
><sampo.creighton.edu!psamuels>
=======_NextPart_000_0038_01BECC8C.A768BEE0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY>
<DIV><FONT color=3D#000000 face=3DCourier size=3D2>I think I've figured =
out the=20
problem, for DOS floppies and other</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DCourier size=3D2></FONT><FONT =
face=3DCourier=20
size=3D2>VFAT file systems at least: </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT> </DIV>
<DIV><FONT face=3DCourier size=3D2>When the system is set to a =
"dual" time=20
zone like EST5EDT and</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>when creating or copying to a VFAT =
file system,=20
Linux uses only</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>the second time zone, i.e., EDT, =
regardless of=20
the system date</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>or file date. However it =
compensates when=20
reading back the</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>files from VFAT to Linux. =
Example: Two=20
files are created in</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Linux (ext2), with the system =
configured so that=20
clock and local</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>time zone are both UTC0, one in =
January and one=20
in July, but </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>both with time 7:00 AM UTC. If =
the system=20
is then reconfigured</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>with both clock and timezone set to =
EST5EDT, 'ls'=20
displays the</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>(ext2) file times correctly in local =
time, i.e.,=20
Jan =3D 2:00 AM (EST)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>and Jul =3D 3:00 AM (EDT). If =
both files are=20
then copied to VFAT floppy</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>(or HDD or ZIP), the files times are =
both written=20
as 3:00 AM and</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>displayed as such by either DOS or =
mdir. =20
(Linux compensates and</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>'ls' on the floppy displays the =
correct 2:00 AM=20
or 3:00 AM).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT> </DIV>
<DIV><FONT face=3DCourier size=3D2>This looks like a bug to =
me.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT> </DIV>
<DIV><FONT face=3DCourier size=3D2>Regarding the CDROM, I've observed =
that with=20
clock and local time</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>set to UTC0, the time displayed for a =
file is=20
identical to that</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>for the same file copied to a VFAT =
file system,=20
so either the</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>ISO9660 file system stores file times =
in UTC or=20
Linux assumes it</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>does. In either case, the file times =
when=20
displayed by 'ls' in</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>EST5EDT have the correct offsets from =
UCT0.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Charles Sullivan </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT> </DIV>
<DIV><FONT face=3DCourier size=3D2>PS: Sorry about the proportional font =
in my=20
original message.</FONT></DIV>
<DIV> </DIV>
<DIV>Peter Samuelson<[EMAIL PROTECTED]> wrote in message <<A=20
href=3D"mailto:7m9agu$uqs$[EMAIL PROTECTED]">7m9agu$uqs$[EMAIL PROTECTED]=
ab.org</A>>...</DIV>>[Charles=20
Sullivan <<A=20
href=3D"mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</A>>]<BR>>=
;> Can=20
someone explain what's going on here?<BR>><BR>>Hmmm, I can=20
try.<BR>><BR>>> Under MS-DOS (Win 98) I copied two files from a =
CD to=20
my hard drive,<BR>>> to a floppy disk, and to a ZIP disk. =
One file=20
has a create date in<BR>>> January, the other in =
July.<BR>><BR>>So=20
after you copied them, are the dates *still* January and =
July?<BR>>I.e. did=20
DOS preserve the CD timestamps or write new ones? I'm =
just<BR>>making=20
sure you're seeing what you think you're seeing. I don't=20
have<BR>>access to an MS-DOS machine (thank goodness) but Windows NT =
4 seems=20
to<BR>>be preserving timestamps on floppies.<BR>><BR>>> I am =
in the=20
Eastern US time zone. My system clock is presently set<BR>>> =
to=20
today's date (10 July 1999) and time, which is Eastern =
Daylight<BR>>>=20
Time.<BR>><BR>>Meaning what? Normally the system (kernel) =
clock is=20
set in UTC, and<BR>>the hardware clock is too. For dual-boot=20
compatibility with legacy<BR>>systems, some distributions offer the =
option of=20
putting the hardware<BR>>clock in local time and correcting the =
kernel clock=20
via a boot script.<BR>><BR>>The time *you* see is governed by =
either your=20
TZ variable or the libc<BR>>default, which is the contents of=20
/etc/timezone. `ls' converts kernel<BR>>time using=20
this.<BR>><BR>>> here's what I get for the time. (This is =
the=20
hour only<BR>>[...]<BR>>> File MS-DOS Linux=3D>=20
CDROM HDD Floppy ZIP<BR>>> ---- =
====== =20
============= === ====== ===<BR>>>=20
Jan =20
22  =
;=20
17 21 21 =
21<BR>>>=20
July =20
12  =
; =20
8 12 12 =20
12<BR>><BR>>I presumed to "correct" for what looks like=20
proportional spacing in<BR>>your editor. (For shame!) In =
fixed=20
spacing, is the above correct?<BR>><BR>>> If I reset my =
hardware clock=20
to a date in January and reboot Linux,<BR>>> the 'date' command =
reports=20
the date I have set, denoted 'EST'. But<BR>>> the file times =
in the=20
various media reported by ls are identical to<BR>>> those shown=20
above.<BR>><BR>>Yes. The timestamps are the same. And =
you=20
didn't change your<BR>>timezone, so they will be presented the same=20
way. You seem to be<BR>>expecting that if you're in EDT, a =
January file=20
will be listed in EDT.<BR>>Not so -- it was created during =
non-daylight time,=20
so is listed in EST.<BR>>Similarly, a July file is listed in EDT, =
since July=20
is during daylight<BR>>savings. Thus the "reported" =
time will=20
be the same year-round,<BR>>assuming the file timestamp isn't=20
touched.<BR>><BR>>> It looks like Linux is assuming that the CD =
file=20
are UTC and is<BR>>> figuring that out from the DOS date (assumed =
to be=20
Eastern time). Is<BR>>> this correct?<BR>><BR>>Yes =
except=20
substitute "libc timezone" for "DOS date". =
Linux=20
assumes<BR>>the CD was mastered (actually that the ISO9660 filesystem =
was=20
created)<BR>>in UTC. So a January file is reported 5 hours =
behind its=20
actual<BR>>timestamp, a July file 4 hours behind.<BR>><BR>>In =
my=20
limited testing here, it looks like mtools doesn't do =
any<BR>>timezone=20
correction (hey, it's trying to be as much like MS-DOS =
as<BR>>possible so I=20
guess it really shouldn't), but of course regular =
system<BR>>utilities (like=20
GNU fileutils) do.<BR>><BR>>> I don't understand why the =
difference of=20
one hour in the January file on<BR>>> the other =
media.<BR>><BR>>Not=20
sure about that part. Rerun your test, if you will, after=20
typing<BR>><BR>> export TZ=3DUTC0<BR>><BR>>into your=20
shell. That makes `ls' tell you exactly what times =
the<BR>>kernel gives=20
it.<BR>><BR>>-- <BR>>Peter=20
Samuelson<BR>><sampo.creighton.edu!psamuels></BODY></HTML>
=======_NextPart_000_0038_01BECC8C.A768BEE0==
------------------------------
** 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
******************************
