Subject: Linux-Development Digest #26
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Mon, 15 Aug 94 07:13:05 EDT

Linux-Development Digest #26, Volume #2          Mon, 15 Aug 94 07:13:05 EDT

Contents:
  Re: Registrar for major device #s? (Nick Holloway)
  Re: Weird problem with msdosfs (Alan Modra)
  Future of Linux (Van Dao Mai)
  setting textmode from program (Maarten Boekhold (Who'd you expect??))
  Re: setting textmode from program (Dominik Kubla)
  Re: Sony CDU31A/Floppy driver fix (Harald T. Alvestrand)
  Re: PowerPC Status? General Q's (Harald Milz)
  Re: Kernel change summary 1.1.40 -> 1.1.41 (Rogon Fateless)

----------------------------------------------------------------------------

From: Nick.Holloway@alfie.demon.co.uk (Nick Holloway)
Subject: Re: Registrar for major device #s?
Date: Sun, 14 Aug 1994 21:20:45 +0000

dhinds@allegro.stanford.edu (David Hinds)
>                                                            [...]  With
> other kinds of loadable device drivers, it just means that you have to
> do a little more than just install a driver module -- you'll need to run
> a script or something, to create appropriate device files, and to delete
> them when the driver is unloaded.

The script that will do both the creation and deletion is:
        cd /dev; ./MAKEDEV update

Since the update will remove the devices for the drivers no longer
present in the kernel.

If you want more control, then:

        cd /dev; ./MAKEDEV -v fooey     # to create devices for fooey driver
        cd /dev; ./MAKEDEV -v -d fooey  # to delete devices for fooey driver

The main issue is which of the standard devices to include in this
automatic scheme.  Currently tty is impossible, mem seems dangerous,
as do fd, hd, xd, sd, which will _never_ change major number anyway
(or booting will fail).

-- 
Nick Holloway |  `O O'  | Home: Nick.Holloway@alfie.demon.co.uk
[aka `Alfie'] | // ^ \\ | Work: nickh@parallax.demon.co.uk

------------------------------

From: alan@spri.levels.unisa.edu.au (Alan Modra)
Subject: Re: Weird problem with msdosfs
Date: 15 Aug 1994 04:17:46 GMT

David Holland (dholland@husc7.harvard.edu) wrote:
: rob@pe1chl.ampr.org's message of Thu, 4 Aug 1994 08:36:43 GMT said:

:  > > [floppy time-stamps being off by about two weeks]
:  > 
:  > Probably you have a weird setting of the timezone in Linux?  

: Nope.

: The battery clock is right (within 10 minutes, anyway.) It's on local
: time. 

: clock -r prints the current local time.
: clock -ur prints a time with the correct offset from UTC in the wrong
: direction, exactly as one would expect. (Four hours, that is.)

: Nonetheless, some files I just shipped over right now from the DOS
: machine are showing up as being dated August 19. (It's the 7th, and
: the DOS machine thinks so too.)

:  > As you report the difference to be two weeks, I think the offset between
:  > UTC and localtime has somehow be gotten to be two weeks on your system.
:  > Check the value of the TZ environment variable.

: Not unless there's something weird going on in the kernel that clock
: doesn't see. 

: TZ isn't set.


Get util-linux-1.9 and apply the following patch to clock.c  (or
just get util-linux-1.10 if it's out already)  The following is an
extract from a patch I sent to util-linux's maintainer, Rik Faith.
See note 3f.


3) The major reason for sending in this diff: modifications to clock.c
   a) Fix a few typos in comments and remove reference to making
      clock -u a cron job.  The kernel adjusts cmos time every 11
      minutes - see kernel/sched.c and kernel/time.c set_rtc_mmss().
      This means we should really have a cron job updating
      /etc/adjtime every 11 mins (set last_time to the current time
      and not_adjusted to ???).
   b) Swapped arguments of outb() to agree with asm/io.h macro of the
      same name.  Use outb() from asm/io.h as it's slightly better.
   c) Changed CMOS_READ and CMOS_WRITE to inline functions.  Inserted
      cli()..sti() pairs in appropriate places to prevent possible
      errors, and changed ioperm() call to iopl() to allow cli.
   d) Moved some variables around to localise them a bit.
   e) Fixed bug with clock -ua or clock -us that cleared environment
      variable TZ.  This fix also cured the annoying display of bogus
      day of week on a number of machines. (Use mktime(), ctime()
      rather than asctime() )
   f) Use settimeofday() rather than stime().  This one is important
      as it sets the kernel's timezone offset, which is returned by
      gettimeofday(), and used for display of MSDOS and OS2 file
      times.

diff -ur orig/util-linux-1.9/clock.c util-linux-1.9/clock.c
--- orig/util-linux-1.9/clock.c Thu Jun 23 11:43:29 1994
+++ util-linux-1.9/clock.c      Fri Aug  5 20:24:02 1994
@@ -5,9 +5,14 @@
 #include <getopt.h>
 #include <time.h>
 #include <string.h>
+#include <sys/time.h>
 
 #define USE_INLINE_ASM_IO
 
+#ifdef USE_INLINE_ASM_IO
+#include <asm/io.h>
+#endif
+
 /* V1.0
  * CMOS clock manipulation - Charles Hedrick, hedrick@cs.rutgers.edu, Apr 1992
  * 
@@ -56,8 +61,7 @@
  * c) set your system time using the 'date' command.
  * d) update your cmos time using 'clock -wu' or 'clock -w'
  * e) replace the first number in /etc/adjtime by your correction.
- * f) put the command 'clock -au' or 'clock -a' in your '/etc/rc.local' or 
- *    let 'cron' start it regularly.
+ * f) put the command 'clock -au' or 'clock -a' in your '/etc/rc.local'
  *
  * If the adjustment doesn't work for you, try contacting me by E-mail.
  * V1.2
@@ -68,12 +72,12 @@
  *
  * "I found the explanation and solution for the CMOS reading 0xff problem
  *  in the 0.99pl13c (ALPHA) kernel: the RTC goes offline for a small amount
- *  of time for updateing. Solution is included in the kernel source 
+ *  of time for updating. Solution is included in the kernel source 
  *  (linux/kernel/time.c)."
  *
- * "I modified clock.c to fix this problem and add an option (now default,
- *  look for USE_INLINE_ASM_IO) that I/O instructions were used as inline
- *  code and not via /dev/port (still possible vila #undef ...)."
+ * "I modified clock.c to fix this problem and added an option (now default,
+ *  look for USE_INLINE_ASM_IO) that I/O instructions are used as inline
+ *  code and not via /dev/port (still possible via #undef ...)."
  *
  * With the new code, which is partially taken from the kernel sources, 
  * the CMOS clock handling looks much more "official".
@@ -89,9 +93,6 @@
 /*#define DEBUG */
 /*#define KEEP_OFF */
 
-/* Stupid constants */
-#define SECONDSPERDAY 86400
-
 /* Globals */
 int readit = 0;
 int adjustit = 0;
@@ -117,11 +118,25 @@
 int cmos_fd;
 #endif
 
-#define CMOS_READ(addr)      ({outb(0x70,(addr)|0x80); inb(0x71);})
-#define CMOS_WRITE(addr,val) ({outb(0x70,(addr)|0x80); outb(0x71,(val)); })
+static inline unsigned char cmos_read(unsigned char reg)
+{
+  register unsigned char ret;
+  __asm__ volatile ("cli");
+  outb (reg | 0x80, 0x70);
+  ret = inb (0x71);
+  __asm__ volatile ("sti");
+  return ret;
+}
 
+static inline void cmos_write(unsigned char reg, unsigned char val)
+{
+  outb (reg | 0x80, 0x70);
+  outb (val, 0x71);
+}
+
+#ifndef outb
 static inline void 
-outb (short port, char val)
+outb (char val, unsigned short port)
 {
 #ifdef USE_INLINE_ASM_IO
   __asm__ volatile ("out%B0 %0,%1"::"a" (val), "d" (port));
@@ -130,9 +145,11 @@
   write (cmos_fd, &val, 1);
 #endif
 }
+#endif
 
+#ifndef inb
 static inline unsigned char 
-inb (short port)
+inb (unsigned short port)
 {
   unsigned char ret;
 #ifdef USE_INLINE_ASM_IO
@@ -143,12 +160,13 @@
 #endif
   return ret;
 }
+#endif
 
 void 
 cmos_init ()
 {
 #ifdef USE_INLINE_ASM_IO
-  if (ioperm (0x70, 2, 1)) 
+  if (iopl (3)) 
     {
       fprintf(stderr,"clock: unable to get I/O port access\n");
       exit (1);
@@ -172,31 +190,26 @@
 cmos_read_bcd (int addr)
 {
   int b;
-  b = CMOS_READ (addr);
+  b = cmos_read (addr);
   return (b & 15) + (b >> 4) * 10;
 }
 
 static inline void 
 cmos_write_bcd (int addr, int value)
 {
-  CMOS_WRITE (addr, ((value / 10) << 4) + value % 10);
+  cmos_write (addr, ((value / 10) << 4) + value % 10);
 }
 
 int 
 main (int argc, char **argv, char **envp)
 {
   struct tm tm;
-  struct tm *tmp;
   time_t systime;
   time_t last_time;
-  char *zone;
-  char zonebuf[256];
   char arg;
-  FILE *adj;
   double factor;
   double not_adjusted;
   int adjustment = 0;
-  int i;
   unsigned char save_control, save_freq_select;
 
   while ((arg = getopt (argc, argv, "rwsua")) != -1)
@@ -233,6 +246,7 @@
 
   if (adjustit)
     {                          /* Read adjustment parameters first */
+      FILE *adj;
       if ((adj = fopen (ADJPATH, "r")) == NULL)
        {
          perror (ADJPATH);
@@ -251,18 +265,19 @@
 
   if (readit || setit || adjustit)
     {
+      int i;
 
 /* read RTC exactly on falling edge of update flag */
 /* Wait for rise.... (may take upto 1 second) */
 
       for (i = 0; i < 10000000; i++)   
-       if (CMOS_READ (10) & 0x80)
+       if (cmos_read (10) & 0x80)
          break;
 
 /* Wait for fall.... (must try at least 2.228 ms) */
 
       for (i = 0; i < 1000000; i++)    
-       if (!(CMOS_READ (10) & 0x80))
+       if (!(cmos_read (10) & 0x80))
          break;
 
 /* The purpose of the "do" loop is called "low-risk programming" */
@@ -278,7 +293,7 @@
          tm.tm_year = cmos_read_bcd (9);
        }
       while (tm.tm_sec != cmos_read_bcd (0));
-      tm.tm_mon--;             /* DOS uses 0 base */
+      tm.tm_mon--;             /* DOS uses 1 base */
       tm.tm_wday -= 3;         /* DOS uses 3 - 9 for week days */
       tm.tm_isdst = -1;                /* don't know whether it's daylight */
 #ifdef DEBUG
@@ -286,16 +301,17 @@
 #endif
     }
 
-  if (readit)
+  if (readit || setit || adjustit)
     {
 /*
- * Mktime assumes we're giving it local time.  If the CMOS clock
- * is in GMT, we have to set up TZ to mktime knows it.  Tzset gets
+ * mktime() assumes we're giving it local time.  If the CMOS clock
+ * is in GMT, we have to set up TZ so mktime knows it.  tzset() gets
  * called implicitly by the time code, but only the first time.  When
- * changing the environment variable, better call tzset explicitly.
+ * changing the environment variable, better call tzset() explicitly.
  */
       if (universal)
        {
+         char *zone;
          zone = (char *) getenv ("TZ");        /* save original time zone */
          (void) putenv ("TZ=");
          tzset ();
@@ -303,31 +319,37 @@
          /* now put back the original zone */
          if (zone)
            {
-             if ((strlen (zone) + 4) > sizeof (zonebuf))
-               {
-                 fprintf (stderr, "Size of TZ variable is too long\n");
-                 exit (2);
-               }
+             char *zonebuf;
+             zonebuf = malloc (strlen (zone) + 4);
              strcpy (zonebuf, "TZ=");
-             strcat (zonebuf, zone);
+             strcpy (zonebuf+3, zone);
              putenv (zonebuf);
+             free (zonebuf);
            }
          else
            {                   /* wasn't one, so clear it */
              putenv ("TZ");
            }
          tzset ();
-         printf ("%s", ctime (&systime));
        }
       else
        {
-         printf ("%s", asctime (&tm));
+         systime = mktime (&tm);
        }
+#ifdef DEBUG
+      printf ("Number of seconds since 1/1/1970 is %d\n", systime);
+#endif
     }
 
-  if (setit || adjustit)
+  if (readit)
     {
+      printf ("%s", ctime (&systime));
+    }
 
+  if (setit || adjustit)
+    {
+      struct timeval tv;
+      struct timezone tz;
 /* program is designed to run setuid, be secure! */
 
       if (getuid () != 0)
@@ -336,18 +358,12 @@
          exit (2);
        }
 
-      if (universal)
-       (void) putenv ("TZ=");
-      systime = mktime (&tm);
-#ifdef DEBUG
-      printf ("Number of seconds since 1/1/1970 is %d\n", systime);
-#endif
       if (adjustit)
        {                       /* the actual adjustment */
          double exact_adjustment;
 
          exact_adjustment = ((double) (systime - last_time))
-           * factor / SECONDSPERDAY
+           * factor / (24 * 60 * 60)
            + not_adjusted;
          if (exact_adjustment > 0)
            adjustment = (int) (exact_adjustment + 0.5);
@@ -364,19 +380,23 @@
                  not_adjusted);
 #endif
        }
-#ifdef KEEP_OFF
-      if (0 != 0)
-       {
-#else
-      if (stime (&systime) != 0)
+#ifndef KEEP_OFF
+      tv.tv_sec = systime;
+      tv.tv_usec = 0;
+      tz.tz_minuteswest = timezone / 60;
+      tz.tz_dsttime = daylight;
+
+      if (settimeofday (&tv, &tz) != 0)
        {
-#endif
          fprintf (stderr, "Unable to set time -- probably you are not root\n");
          exit (1);
        }
+#endif
     }
+
   if (writeit || (adjustit && adjustment != 0))
     {
+      struct tm *tmp;
       systime = time (NULL);
       if (universal)
        tmp = gmtime (&systime);
@@ -384,10 +404,11 @@
        tmp = localtime (&systime);
 
 #ifndef KEEP_OFF
-      save_control = CMOS_READ (11);   /* tell the clock it's being set */
-      CMOS_WRITE (11, (save_control | 0x80));
-      save_freq_select = CMOS_READ (10);       /* stop and reset prescaler */
-      CMOS_WRITE (10, (save_freq_select | 0x70));
+      __asm__ volatile ("cli");
+      save_control = cmos_read (11);   /* tell the clock it's being set */
+      cmos_write (11, (save_control | 0x80));
+      save_freq_select = cmos_read (10);       /* stop and reset prescaler */
+      cmos_write (10, (save_freq_select | 0x70));
 
       cmos_write_bcd (0, tmp->tm_sec);
       cmos_write_bcd (2, tmp->tm_min);
@@ -397,8 +418,9 @@
       cmos_write_bcd (8, tmp->tm_mon + 1);
       cmos_write_bcd (9, tmp->tm_year);
 
-      CMOS_WRITE (10, save_freq_select);
-      CMOS_WRITE (11, save_control);
+      cmos_write (10, save_freq_select);
+      cmos_write (11, save_control);
+      __asm__ volatile ("sti");
 #endif
 #ifdef DEBUG
       printf ("Set to : %d:%d:%d\n", tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
@@ -411,6 +433,7 @@
   /* Save data for next 'adjustit' call */
   if (adjustit)
     {
+      FILE *adj;
       if ((adj = fopen (ADJPATH, "w")) == NULL)
        {
          perror (ADJPATH);


------------------------------

From: mai@wumpus.cc.uow.edu.au (Van Dao Mai)
Subject: Future of Linux
Date: 15 Aug 1994 17:17:08 +1000

Guys,
   I read a debate on comp.os.linux.misc about some people thinking of
Linux as only a toy. I like it very much as it is free and smarter than
many commercial systems. It has faults that are common of all UNIXes.
   I suppse one has to be clear of the purpose of a system to see its
value. If UNIX is still targeted at education mainly then it is fine as 
it is. However if it is targeted at normal users then it is not.
   What Linux needs are a better graphical interface and editing tools.
Apart from this it has to have a better facility for printing so that
more printer drivers can be supported. The main problem is that it is a
free system without real money to support large scale integrated projects
aiming at these needs. Imagine how one would create a word processing
system like MSWord or Ami Pro?  There are brilliant programmers who
created nice utilities falling short of an integrated package that will do
a lot of things.
   It owuld be nice if people create large long term projects to give
Linux decent software that can be given out or sold for small profit to go
back to the development of more software. A limited commercialism in this
sense with the money to support programmers and the development of this
system. Provided that good projects are set up and co-ordinated, I think
volunteers can be found to contribute into the project rather than doing a
complete software utility, nice but too small to be significant. This will
also stop people re-inventing too many wheels.
   1- Companies selling Linux CDs and support. They should be asked to
      donate a part of their income back into Linux development.
   2- Projects should be started and co-ordinated by talented people so
      that programmers can contribute to this in an integrated manner.
   3- Linux users should be encouraged to become members of a Global 
      Linux Club and membership fee will beused to support programmers
      working on Linux Software Projects.

May be this will give us a good set of Linux software that will make it on
the same footing as Windows, OS/2 or DOS. The most urgent things to have t
for Linux is (1) a decent object-oriented filemanager for X windows and
(2) A powerful word processing with GUI interface for Linux. These two
would make the system a lot more useable for all people. 

This will make Linux a home UNIX system for many "better than average"
computer user.

Cheers,

Van Dao Mai
Wollongong Australia

------------------------------

Subject: setting textmode from program
From: boekhold@morra.et.tudelft.nl (Maarten Boekhold (Who'd you expect??))
Date: 15 Aug 94 11:12:31 +0200

Hi,

I was wondering if it is possible to set the textmode of the active VC 
from a user-program (if necessary setuid root). I guess it must be 
possible, since lilo (or is it the kernel?) can do it on startup (and 
under dos you can use 'mode con: lines=' or something like that).

So what I want is to enable the user of the program to change the 
textmode of the VC from a menu-item or config-file from ('standard') 
80x25 up to 132x43 or whatever is possible with the video-card.

I'm aware that different videocards have different textmodes, so maybe 
this is a feature that should be build into svgalib (or maybe it already 
is ??) to be fully interchangable with other linux-boxes. This addition 
then would include a text-specific init-function, a function to query the 
available modes and one to change them (a text-specific init-function for 
not blowing the program if you're not using graphics, so the function 
would not mmap the graphics-mem, only the text-mem, or doesn't this make 
any difference? guess not....).

Maarten
boekhold@morra.et.tudelft.nl

------------------------------

From: kubla@dagobert.zdv.Uni-Mainz.DE (Dominik Kubla)
Subject: Re: setting textmode from program
Date: 15 Aug 1994 10:02:16 GMT

Nope! Currently this is not possible! all the kernel does at boot time
is setting the req. video mode via BIOS call while still in real-mode.

But be patient, i am working on this subject ...

Cheers,
  Dominik
===========================================================================
eMail: Dominik.Kubla@Uni-Mainz.DE    sMail: Dominik Kubla, Lannerstrasse 53
                                            55270 Ober-Olm, F.R. of Germany
>>> Save the environment NOW! <<<           ******  European  Union  ******

------------------------------

From: hta@uninett.no (Harald T. Alvestrand)
Subject: Re: Sony CDU31A/Floppy driver fix
Date: 15 Aug 1994 10:18:07 GMT

The *proper* way to do this is to have the kernel reserve only the
parts of the I/O space needed for the floppies it actually finds.

(Another prayer for the floppy driver: detecting a floppy that becomes
available....my removable floppy doesn't work unless it's present at
boot time....but this may be another problem, more PCMCIA related....but
it WILL eventually have to change the floppy-driver....)
-- 
                   Harald Tveit Alvestrand
                Harald.T.Alvestrand@uninett.no
      G=Harald;I=T;S=Alvestrand;O=uninett;P=uninett;C=no
                      +47 73 59 70 94
My son's name is Torbjxrn. The letter between "j" and "r" is o with a slash.

------------------------------

From: hm@seneca.ix.de (Harald Milz)
Subject: Re: PowerPC Status? General Q's
Date: Mon, 15 Aug 1994 07:33:55 GMT
Reply-To: hm@seneca.ix.de

Philippe Steindl (psteindl@il.us.swissbank.com) wrote:

: > what's the status of the Linux PPC port? Is it planned to run on the  
: > coming PCI 604 etc generation? Thanx

According to the Projects-FAQ:

Title:          Linux/PowerPC 
Desc1:          A port of the Linux 1.0 kernel to the PowerPC platform. Our curr
ent 
Desc2:          hardware is an Apple PowerMac 7100/66, but we intend it to run 
Desc3:          on all PowerPC/PCI/SCSI platforms (essentially, the current 
Desc4:          PReP hardware plus some Power Macs.) 
Desc5:          
Author:         A team of five people; contact Charlton Wilbur or Jem Lewis. 
AuthorEmail:    cwilbur@polar.bowdoin.edu; jlewis@polar.bowdoin.edu 
InfoSources1:   None yet; mailing list/WWW site on the way. You can sometimes 
InfoSources2:   read interesting speculation on comp.sys.powerpc. 
InfoSources3:   PowerPC news mentions us every now and again. 
Assistance:     not required 
CurrentStat:    some development tools ported; kernel in 1st code runs 
ETA:            kernel, Sept 94; device drivers, good question. 
Remarks1:       The biggest FAQ we've run into: 
Remarks2:       This runs *instead* of System 7, not on top of it or 
Remarks3:       on top of SoftWindows. Although I don't think it's been 
Remarks4:       tried, Linux probably won't run on top of SoftWindows because 
Remarks5:       it only emulates a 286 at the moment. 

I guess this answers your questions. 
-- 
Harald Milz (hm@seneca.ix.de)
iX Multiuser Multitasking Magazine

------------------------------

From: rogon@engstad.tromsomh.no (Rogon Fateless)
Subject: Re: Kernel change summary 1.1.40 -> 1.1.41
Date: Mon, 15 Aug 1994 10:58:18 GMT

Thanks for this wonderful referee of kernel changes!
Is it possible to have these files inside the kernel tree? 
Or, perhaps mirror them to the major ftp-sites?

o-----------------------------o----------------------------------------o
| Rogon the Fateless, aka     | Work: Tromsoe College, Section of      |      
|     Paul-Kristian Engstad,  |       Economics and Engineering,       |
|     Otervegen 58,           |       Postboks 72,                     |
|     N-9017 Tromsoe, Norway. |       N-9001 Tromsoe, Norway.          |
|     +47 77 67 03 88 (P)     |       +47 77 68 02 50                  |
|                             |       +47 77 61 12 00 --- 235 (Direct) |
o-----------------------------o----------------------------------------o
| Email: engstad@marind.tromsomh.no  : Work, MS-Windows.               |
|        rogon@engstad.tromsomh.no   : Linux!!                         |
o----------------------------------------------------------------------o

------------------------------


** 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: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************
