diff --git a/Linux-0.95/INSTALL/autocn/ACONVERT.EXE b/Linux-0.95/INSTALL/autocn/ACONVERT.EXE new file mode 100644 index 00000000..de51a664 Binary files /dev/null and b/Linux-0.95/INSTALL/autocn/ACONVERT.EXE differ diff --git a/Linux-0.95/INSTALL/autocn/AUTOCON.DOC b/Linux-0.95/INSTALL/autocn/AUTOCON.DOC new file mode 100644 index 00000000..6e3bdbe2 --- /dev/null +++ b/Linux-0.95/INSTALL/autocn/AUTOCON.DOC @@ -0,0 +1,1234 @@ + + + + + + + + + + + A U T O C O N + Version 2.0g + March 15, 1992 + + by + Larry Weaver + + + Copyright (c) 1989-92 Larry Weaver + + P.O. Box 2639 + Weaverville CA 96093-2639 + Office : (916) 623-5045 + BBS : (916) 623-4455 + + + + + _______ + ____|__ | (tm) + --| | |------------------- + | ____|__ | Association of + | | |_| Shareware + |__| o | Professionals + -----| | |--------------------- + |___|___| MEMBER + + + AUTOCON + + Introduction + + Definitions: + + In order to describe AutoCon, I need to establish a couple of + definitions. When I use the word "reconfigure", I mean the + process of updating the AUTOEXEC.BAT and CONFIG.SYS files on the + boot drive, followed by an optional reboot of the system. + + When I use the word "configuration", I am referring to an + AUTOEXEC/CONFIG combination held in a record of AutoCon's + database. You will use AutoCon to set up these combinations, and + give each of them a familiar name. + + The ^ symbol denotes the Control key, so ^F3 means hitting the + Control and the F3 key at the same time. Alt denotes the Alt key + (tricky, huh?), so that AltR means hitting the Alt and the R key + at the same time. ENTER (all caps) denotes hitting the Enter key. + + + Description: + + AutoCon is essentially a database manager for your AUTOEXEC.BAT + and CONFIG.SYS files. It enables you to keep up to fifty + different configurations, and to change easily between those + configurations. + + The first time you run AutoCon, it will create a file named + AUTOCON.DAT. That file will contain five configuration records. + Each record will contain a copy of the AUTOEXEC.BAT and + CONFIG.SYS files from the C: drive. The records are initially + named RECORD01 - RECORD05. When you set up a configuration for a + specific purpose, you can change the name to reflect that purpose + (something like Win3 for a Microsoft Windows configuration, and + SDOS for a simple DOS configuration). You can add more records by + hitting the F3 key. + + AutoCon incorporates a full-screen editor to make it easy to + change the AUTOEXEC/CONFIG records. The editor uses Turbo + IDE/Sidekick/WS-compatible keystrokes. If you are not familiar + with these, there is an on-line help file which details all the + keystrokes. If you desire, you can change the editor keystrokes. + The F6 key will pop up a key editor for this purpose. + + If you don't like the built-in editor, you can configure AutoCon + to use a different one. The ^F6 key combination will pop up a + window asking for the name of the editor you wish to run. Since + the configurations will eventually be used as AUTOEXEC.BAT and + CONFIG.SYS files, the editor must be able to produce pure ASCII + files. You can toggle between the internal and external editors + with the ^F6 and the ShiftF6 key combinations. + After you have established your records and names, you can + reconfigure your system by entering the name of the new + configuration on the command line. Typing "AutoCon Win3" would + cause AutoCon to copy the AUTOEXEC and CONFIG fields of the + record named Win3 into the boot drive as AUTOEXEC.BAT and + CONFIG.SYS and optionally reboot the system. + + In the interactive mode, you can page through the records and + reconfigure (using the current on-screen configuration) with a + couple of keystrokes. + + The AutoCon package also includes a device driver which will + allow you to select different configurations during the boot + process. Using this method is optional, and you can switch + between the two methods with a couple of key strokes. + + + Why AutoCon for Configuration Control: + + Three programs were initially responsible for the creation of + AutoCon: my schematic program, my scanner program, and my + programmable logic compiler. Each of these programs require + various device drivers, and almost 600k of memory. When the + computer is configured to run one of the three, neither of the + other two will run; in addition, if the computer is configured the + way I like to work with it, _none_ of the three will run. After + playing with batch files for a while, I decided to write a program + to make it easy to change configurations. + + The above scenario is responsible for the default of five records + in AutoCon. I had a regular configuration, the three special + configurations, and one for experimentation. After I had worked + with AutoCon for a few days, I told a few of my friends about the + program and they wanted to try it. After some very positive + feedback, I decided to try the program out in the Shareware + community. + + An unexpected bonus of using AutoCon became evident when I + received programs with automatic installation modules -- you know, + the ones that like to mess around with your AUTOEXEC and CONFIG + files. Since your configurations are stored in a database, a + change to the AUTOEXEC and CONFIG files doesn't cause a problem. + + I'll use Windows to demonstrate. When I got Windows, and saw + what it was going to do to my system configuration, I used my + "Simple" configuration to reconfigure my system. This + configuration has only the basic stuff in it (path, prompt, + files, and buffers). I then let Windows install itself. After + the installation was finished, I called up AutoCon and created a + new configuration containing the changes Windows had made. After + playing with Windows for a while, I went back to my favorite DOS + configuration in a matter of moments. Now, whenever I want to + run Windows, I just type "AutoCon Win3" on the command line -- + and it's up and running! + INSTALLING AUTOCON + + New Installation: + + To do a new installation of AutoCon, you need to copy four files + (AUTOCON.EXE, AUTOCON.HLP, MENU.CTL, and MENUNUM.COM) to your + hard disk. It doesn't really matter which subdirectory you copy + them into, as long as it's included in the PATH statement. If + you like to have files relating to booting up (such as device + drivers) in your root directory, then MENU.CTL and MENUNUM.COM + should be placed there, otherwise all four files may be placed in + the same subdirectory. When AutoCon is started, it will first + look in the current subdirectory for its Help and data files. If + they are not there, then AutoCon (if you are using DOS 3.3+) will + search the subdirectory it was started from. If they are not + _there_, then AutoCon will search the PATH. As long as the Help + and data files are in the PATH (or in the subdirectory AutoCon + was started from - DOS 3.3+), AutoCon can be installed in any + subdirectory. + + After you have copied the files, change to the subdirectory + AUTOCON.EXE was copied to, and type "AUTOCON" ENTER. You will now + be in the interactive mode, pointing to the name of the first + configuration. This first configuration is a special one to + AutoCon. Several of the default parameters are stored in this + configuration. When you make changes to the first record, you + will be asked whether you want to copy those changes across all + the records. + + IMPORTANT: If you are currently using a disk cache program that + buffers disk writes (PC-KWIK and PCTOOLS are two that I know of), + you need to set up AutoCon to flush the cache before it reboots. + Hit the F4 key, select "Yes", then enter the command (include the + path if necessary) that causes your cache program to flush its + buffers. In the case of PC-KWIK, it is the PC-KWIK program name + followed by /F. AutoCon will execute this program before + reconfiguring. + + AutoCon is now installed, and ready to use. + + + Update: + + If your current AutoCon version is below 2.0 then the new + capabilities of AutoCon require a change to the AUTOCON.DAT file, + so if you are updating to V2.0x of AutoCon from 1.x you have a + little more to do: you need to copy the same four files mentioned + above to the subdirectory where the older version of AutoCon + (which will be overwritten) is installed. There is another new + file in the AutoCon package called ACONVERT.EXE. You need to + change to the subdirectory where AUTOCON.DAT resides, then run the + ACONVERT program. This program will rename AUTOCON.DAT to + AUTOCON.SAV, then convert the file structure to work under AutoCon + V2.0x. After you run ACONVERT.EXE, you no longer need the + ACONVERT.EXE file, so it can be deleted. + + The editor has a few new capabilities which will not be available + until you change the editor keys. Call up AutoCon, then hit the + F6 key. If you have never changed the keys, hit AltR, and + answer "Yes" to restoring the default keystrokes. If you have + changed the keystrokes, page down to the bottom of the key list; + you will see that there are some new keys that need to be + defined. + + In either case, after copying the files, you will need to start + AutoCon and hit the F2 key. Answer yes to update the files to the + new version. + + MENU.CTL & MENUNUM.COM + + The addition of these two files to the AutoCon package changes + its capabilities so much that I decided to skip versions 1.5 - + 1.9 and go directly to version 2.0. MENU.CTL is a device driver + which modifies the way a CONFIG.SYS file is processed by DOS. It + allows AutoCon to set up a menu selection system which can be + activated during the boot process. There are both advantages and + disadvantages to this capability; the major advantage is that you + can pick the configuration you want to use during the boot + process. + + The major disadvantage is that your CONFIG.SYS and AUTOEXEC.BAT + files become quite nonstandard. If you want four choices to be + available to you during the boot, then all four configurations + must be embedded in the AUTOEXEC and CONFIG files. Programs like + Optimize (QEMM utility) will get very confused trying to work + with these files; most automatic installation programs will not + be able to work with them, either. + + I've designed AutoCon to be able to switch between the boot "menu" + mode and the "single" mode with just a couple of keystrokes; this + should provide the best of both worlds. When a program like + Optimize (or perhaps the Windows installation program) needs to + work with your AUTOEXEC and CONFIG files, change to the single + configuration mode. After the program is finished, call up + AutoCon, save the results in one of your configurations, and go + back to the menu mode. + + + MENU.CTL: + AutoCon handles all the nitty-gritty details of interfacing to + MENU.CTL. The only thing you have to do is make sure that + MENU.CTL and MENUNUM.COM are in a subdirectory included in the + PATH statement. To set up MENU.CTL, start AutoCon in the + interactive mode (just type "AUTOCON" ENTER), then hit the AltM + key combination; this will pop up a configuration menu. Select + the configurations you want in the boot-up menu by moving the + highlite bar over the ones you want, and hit the Enter key. The + selected configurations will have a check mark in the first + column. When you've finished selecting configurations, hit the + Escape key. AutoCon will then ask how many seconds you want to + delay (see the following note). Enter a number from 0 to 9. + + You will now be back in the main interactive screen. Hit the F2 + key to reconfigure the system using MENU.CTL (the record on the + screen will be made the boot default record -- if it was not one + of the selected records, it will be added to the default list). + The next time you boot, MENU.CTL will take control of the + CONFIG.SYS file. If you hit a key in the default time, you will + be able to choose from the configurations you selected. + + To go back to a single configuration, start AutoCon in the + interactive mode, and hit the AltS key combination. Change to the + configuration you want to boot with, hit the F2 key, and + you're reconfigured, + + You will always be able to tell which mode AutoCon is in by + looking at the bottom line on the screen in the interactive mode. + If it says MENU.CTL you are in (boot) Menu mode, and if it says + SINGLE you are in Single Mode. + + Time: + When you select Menu mode, you will be asked to select how many + seconds to wait during the boot process; you may enter from 0 + (the default) to 9. If you select 0, when you see the MENU.CTL + box pop up, you will have about a second to hit a key. If you do + hit a key in this time, the menu selection will be placed on the + screen. If not, the boot will continue with the default record. + + If you select any number except 0, you will see the following + messages on the screen during the boot process: + + Press Esc to select -- the default record name will be here -- + + Press any other key to select a different configuration. Time = + + with a decrementing number (starting with the time chosen from + AutoCon) following the = sign. When the time goes to 0, or the + Esc key is hit, the default record will be used to continue + the boot. + + In either case, if a key is hit, the menu choices will be placed + on the screen and you will be able to choose the one you want with + the arrow keys. The one the arrow is pointing to when the ENTER + key is hit will be the configuration used for the boot process. + + Colors: + If you don't like the colors that MENU.CTL uses when it takes + control of the boot process, you can change them using the pull + down menu in AutoCon. Start AutoCon, and hit the AltB + combination. The four colors used by AutoCon can be changed with + this menu. Select the colors you would like MENU.CTL to use, then + write out the new configuration (usually with the F2 key). + + + XMAEM.SYS: + I don't have DOS 4.0, so I don't really have experience with this + device driver. From reading PC Magazine, I know that DOS + processes this device driver out of sequence in the CONFIG.SYS + file. As a consequence, MENU.CTL will not be able to control it. + + + MSDOS 5.0's High and UMB flags: + Microsoft added a couple of capabilities to DOS 5.0 that pose a + special problem for MENU.CTL. These are the DOS=HIGH/LOW and + DOS=UMB/NOUMB flags. DOS processes these flags out of sequence, + so that by the time MENU.CTL has taken over, it has already set + itself up for their use. DOS decides how to set the flags by + parsing the entire CONFIG.SYS file, and using the state of the + last occurrence of the DOS= statement to set the flags. + + AutoCon is still able to control these flags though the method is + a little unorthodox. When you are using Menu mode and MSDOS 5.0, + AutoCon will place the statement DOS=HIGH,NOUMB as the last line + in the CONFIG.SYS file. As a consequence, DOS will attempt to + always load HIGH, and have NOUMB control. When you select a + configuration via MENU.CTL, if that configuration has a DOS=LOW + command in it (and no other program in the configuration has taken + it), MENU.CTL will take the HMA and force DOS Low. The HMA will + be released by MENUNUM runs (as soon as the AUTOEXEC.BAT file + starts executing). If the selected configuration has a DOS=UMB + command, then MENU.CTL will tell DOS to control the UMBs. + + If all of this makes no sense to you, then don't worry about it. + If you are using MSDOS 5.0 and the Menu mode, just place the + appropriate DOS=HIGH/LOW and DOS=UMB/NOUMB commands in each of + your configurations, and AutoCon will do the rest. + + + DRDOS: + As of this release MENU.CTL (Version 1.4 or higher) if fully DRDOS + compatible. + + + CONFIG: + When you switch to the Menu mode, AutoCon will do all of the work + for you. It will take your selected configurations (up to 8) and + create the AUTOEXEC.BAT and CONFIG.SYS files that will allow you + to choose during the boot process. If you look at the CONFIG.SYS + file that has been set up for a boot menu, you will see all the + selected CONFIG fields embedded in the files with DEVICE=MENU.CTL + at the beginning of the file. When MENU.CTL is processed by DOS, + it will take over and allow you to choose the configuration you + want. After you choose, MENU.CTL will leave the chosen + configuration intact and disable the rest. + + If you are using DOS 4.0+, MENU.CTL disables by changing the + CONFIG.SYS commands to remarks. If you are using DOS 3.3 or + below, it will disable the commands by turning them into + BREAK=OFF commands. As a consequence, if you are using a DOS + below 4.0, you will need to make a couple of changes to your + CONFIG commands. In order to have the room to convert the + LASTDRIVE, FILES, and BUFFERS commands, you will need to make the + lines longer. + + I do this by adding an * at the end of the line, as follows: + LASTDRIVE=M: * BUFFERS=10 * FILES=50 * + + If you don't do this, these commands will be disabled by making + them unrecognized. This doesn't cause a problem: you will just + see a lot of "Unrecognized command in CONFIG.SYS" lines coming + out during the boot process. + + Note: AutoCon will also change "Unrecognized" commands to + BREAK=OFF commands if there is room. This will allow you to + freely place REM statements in your CONFIG.SYS file (as long as + you use MENU mode). + + If you want BREAK=ON, you will have to add it to your AUTOEXEC + fields. + + AUTOEXEC: + The AUTOEXEC.BAT file will also contain all the selected + configurations AUTOEXEC fields. At the beginning of the file + will be MENUNUM.COM. This program will interrogate MENU.CTL and + find which configuration was chosen. MENUNUM will set ERRORLEVEL + to match the chosen menu, and an "If" statement will cause the + associated AUTOEXEC to be chosen. + + UNRECOGNIZED COMMANDS - DOS 3.3: + CONFIG.SYS files have a potential problem. If you enter the + following two lines in your CONFIG.SYS file + + REM + DEVICE=ANSI.SYS + + ANSI.SYS will not get loaded. Both lines will be turned into an + "Unrecognized command". This is just something that DOS does, + and there is nothing an outside program can do about it. + + Do not end a CONFIG field with an Unrecognized command. If you + do, the following command will also be Unrecognized, and will + definitely mess up the processing of the CONFIG.SYS file. + + CAUTION: When you start playing around with the Menu mode, be very + careful when updating or creating a configuration. If you read + in an AUTOEXEC.BAT or CONFIG.SYS file which has been set up for + MENU mode, it will contain a lot of commands which will cause + problems if you use it in a reconfiguration. It would be much + better to copy one of the other configurations and not update + from the AUTOEXEC and CONFIG files. + + If you have managed to read and save such a configurations, you + will need to edit and remove the extra statements inserted by + AutoCon. If it is not obvious to you by looking at the AUTOEXEC + and CONFIG fields which statements these are, then do not attempt + to edit the field, simply copy one of the other configurations. + + Magazine Article: + Just as a side note, during the development of MENU.CTL I created + a simpler device driver and decided it would make a good subject + for a magazine article (similar to PC Magazine's CONFIG.CTL + device driver). I wrote it up, and it was published in the Sept. + 1991 issue of Tech Specialist. + + + + NAVIGATING AUTOCON + + + Okay, now you have AutoCon installed; how do you use it? Starting + with version 2.0, the interactive front screen of AutoCon can be + navigated with a pull-down menu. If you need to do something and + can't remember the keystroke combination to get there, use the + menu to find it. On the right of each menu entry is the shortcut + key combination to perform the same operation. I am going to + define the navigation keys in the form of the pull-down menu. + + DataBase Maintenance (Records AltR) + + Previous/Next, browse records: + PgUp/PgDn allows you to page through the records one at a time. + + pIck Record: + F10 pops up a pick-list of all the configurations, and allows + you to choose one and make it current. + + Create Record: + F3 creates a new record, and copies the control structure from + record 1 and the data from the current AUTOEXEC and CONFIG + files. + + Delete Record: + ^F3 deletes the current configuration record. Note that you + cannot delete record number 1, nor can you delete below the + default 5 records. + + Read Files: + F7 will cause the current record to be updated with the + contents of the AUTOEXEC and CONFIG files. + + Read file into AUTOEXEC (rd Auto ^F8): + ^F8 will pop up a window asking for a file name to read into + the AUTOEXEC field. In you enter wildcards, a list of file + names will be popped up to choose from. The AUTOEXEC field of + the current record will be replaced by the contents of the + chosen file. + + Read file into CONFIG (rd confiG ^F9): + ^F9 will pop up a window asking for a file name to read into + the CONFIG field. In you enter wildcards, a list of file names + will be popped up to choose from. The CONFIG field of the + current record will be replaced by the contents of the chosen + file. + + Configure and continue: + ^K^D will cause all current changes to be saved. In other + words, it will rewrite the AUTOCON.DAT file, the AUTOEXEC.BAT + file, and the CONFIG.SYS file. + + Change BAT drive: + F8 will pop up a window to allow you to change the file the + AUTOEXEC field of a configuration is written too. The default + name is C:\AUTOEXEC.BAT. + + Change SYS drive: + F8 will pop up a window to allow you to change the file the + CONFIG field of a configuration is written to. The default + name is C:\CONFIG.SYS. + + cOmpare: + Alt= will compare the current configuration with the contents of + the current AUTOEXEC and CONFIG files. It should be noted that, + if you are using the MENU.CTL device driver option, this + comparison will probably not be applicable. + + boot Type: + F5 will pop up a window to allow you to change the boot type + associated with a configuration. The choices are Warm, Cold, + None, and External. + + Flush: + F4 will pop up a window that will allow you to associate a + cache Flush command with the current configuration record. This + is necessary when the cache used in the configuration does a + write cache operation (PC-KWIK and PCTOOLS both default to this + configuration). + + cLone: + AltC will allow you to clone (or copy) the contents/control + of one of the other configurations to the current + configuration. It will pop up a pick list of all of the + existing configurations, and allow you to pick the one to copy + from. + + If you are using the AutoCon environment variable, you will + need to edit the AUTOEXEC file, and make sure the correct name + is used. + + Update: + ^K^S will save all current record changes to the AUTOCON.DAT + database file. Note that it will not update the AUTOEXEC and + CONFIG Files. You must use ^K^D for that. + + rEstore: + ^K^R will abandon all changes you have made (since the last + AUTOCON.DAT save) and reload the database records from the + AUTOCON.DAT file. + + + Boot Operation (Boot AltB): + + Single: + AltS configures AUTOCON to use only the current record for + reconfiguration purposes. + + Menu: + AltM configures AutoCon to use MENU.CTL in conjunction with + MENUNUM.COM to set up a selection menu to be used during the + boot process. A pick list of the current configurations will + be popped up, and you will be able to choose up to eight + default configurations to be included. After you have chosen + the eight, you will be asked how many seconds to delay during + the boot process. If a number other than 0 is entered, a + message will be placed on the screen during the boot process, + and MENU.CTL will wait that many seconds for a key to be hit. + + Boot Frame: + When booting under menu mode, MENU.CTL pops up some windows + and this selection allows you to change the color of the + window frames of those pop up windows. + + Boot Text: + When booting under menu mode, MENU.CTL pops up some windows + and this selection allows you to change the color of the text + in those pop up windows. + + Boot Attention: + When booting under menu mode, MENU.CTL pops up some windows + and this selection allows you to change the color of the text + used to draw your attention. This is the color of the + decrementing time variable, and the color that will be used + for warning messages. + + Boot Hi_Lite: + When booting under menu mode, MENU.CTL pops up some windows + and this selection allows you to change the color of the + moving selection hi-lite bar used to select a boot + configuration. + + + Editor options (Editor AltE): + + Internal: + ShiftF6 configures the current configuration to use the + internal editor. + + External: + ^F6 configures the current configuration to use an external + editor. A window will pop up asking for the editor's name. You + may include a path in the name, but you must include the + extension (e.g., WORD.EXE or C:\WORD\WORD.EXE). The next time + you edit the AUTOEXEC or CONFIG field for this record, if the + external editor can be found it will be used. If it can't be + found, AutoCon will switch back to the internal editor. + + After the external editor has been installed, it will be used + to edit the AUTOEXEC and CONFIG fields from the main screen. + When you move the cursor to the AUTOEXEC or CONFIG field and + press enter, AutoCon will copy the current record to the + current subdirectory as XYZXYZZ.XYZ (the current subdirectory + must contain at least 4k of disk space). AutoCon then shells + to DOS with the editor name and filename on the command line + (e.g., WS.EXE XYZXYZZ.XYZ). When you exit your editor, AutoCon + should restart. It will copy the XYZXYZZ.XYZ file into the + AUTOEXEC field of the current record and delete the XYZXYZZ.XYZ + file from the subdirectory. + + + CAUTION!! Just to make sure there is no problem with your + editor, create a new record and work with it first, before + taking the chance of harming one of your current records. You + may want to make a copy of your AUTOCON.DAT file and store it + in a safe place until you've verified the operation of the new + release. In fact, you should always keep a backup copy of + AUTOEXEC.DAT. + + + Install Keys: + F6 will pop up a window that will allow you to change the + keystrokes used in the internal editor. F6 may also be used + while in the internal editor to see exactly which key performs + which function. + + Save Keys: + This function is really added for future action (though it is + fully functional in this release). If you have modified the + keystrokes to emulate your favorite work processor, how about + saving them, then upload them to my BBS. + + Get Keys: + This function will allow you to change AutoCon's editor + keystrokes quickly by reading in a keystroke file. + + + coLors AltL: + + Frame: + AltF1 pops up a color pick window which allows you to change + the color of the frames drawn around the windows on the main + interactive screen. + + Frame Text: + AltF2 pops up a color pick window which allows you to change + the color of the text in the windows on the main screen. + + Background: + AltF3 pops up a color pick window which allows you to change + the color of the text and/or background of the main screen. + + Field: + AltF4 pops up a color pick window which allows you to change + the color of the fields that get updated on the screen, the + configuration name, the date and time, the record number, and + the select boxes. + + Prompt: + AltF5 pops up a color pick window which allows you to change + the color of the current select box. This is the color of the + main screen select item that the cursor is positioned to. + + Edit Text: + AltF6 pops up a color pick window which allows you to change + the color of the text used in the editor. + + Marked Text: + AltF7 pops up a color pick window which allows you to change + the color of the text used to show marked blocks in the editor. + + Ctrl Text: + AltF8 pops up a color pick window which allows you to change + the color used to show control characters (value < 20 hex) in + the edit text. + + Menu Frame: + This menu item allows you to change the color of the frame + around the pulldown menus. Note that there is no hotkey. + + Menu Text: + This menu item allows you to change the color of menu items in + the pulldown menus. Note that there is no hotkey. + + Menu Select: + This menu item allows you to change the color of the currently + selected item in the pulldown menus. Note that there is no + hotkey. + + Menu Hi-lite: + This menu item allows you to change the color of the Hi-lited + select character in the pulldown menus. Note that there is no + hotkey. + + Help fRame: + This menu item allows you to change the color of the Frame drawn + around the Help Window (also changes the color of one of the + basic Help Hi-Lite color). + + Help tExt: + This menu item allows you to change the color of the text in the + Help Window. + + Help heAder: + This menu item allows you to change the color of the Header on + the Help window. It will also be the default color of the Help + menu select color. + + Default: + AltF10 pops up a color pick window which allows you to + change all configurable colors back to the defaults. If your + screen goes black, hit AltF10 followed by the Y key, and you + may be able to see the screen again. + + + Quit AltQ : + + Configure: + F2 reconfigures the system. It will save any record changes in + the database file, and create new AUTOEXEC and CONFIG files. It + will then perform the requested reboot. + + Reboot: + This menu item will cause any record changes to be saved in the + database file, and force the default reboot action. Note that + there is no hotkey. + + Exit: + This menu item will save any record changes in the database + file and exit without any reboot action -- a rough equivalent + to hitting the ESC key. + + Abandon/Exit: + ^K^Q will cause any current record changes to be abandoned, and + AutoCon will exit without any reboot action. + + Restore Screen?: + This function can only be reached through the pull down menu. + If you set this to "NO", then AutoCon will not attempt to + restore the original screen on exit. Some video combinations + seem to have a problem with the restoration, so you can turn it + off. + + + Keys not in the Menu: + + AltV : + This key combination will show you the DOS screen as it was + when AutoCon was activated. + + + + + COMMAND LINE OPTIONS + + Environment: + For AutoCon to work correctly with the command-line commands, it + will need to know which configuration was used for the last boot- + up. There is only one sure way for AutoCon to get this + information: if you are using the Menu mode, MENU.CTL will be + able to tell AutoCon which configuration was chosen. + + If you are using the Single mode, to make sure that AutoCon knows + which configuration was used to boot, you need to add a line to + your AUTOEXEC fields. The line is as follows: + + SET AUTOCON= + + in which "configuration name" is the name that shows up on the + front screen in the interactive mode. To make it very easy, a + new key-stroke command was added to the editor. The default key + is AltE. Place your cursor at the position in the AUTOEXEC + field where your other SET commands are located, and press the + AltE combination. AutoCon will insert the proper line in the + file. + + + Reconfigure: + To reconfigure from the command line, type + + AUTOCON ENTER + [e.g., AUTOCON WIN3 ENTER] + + on the command line. As long as AUTOCON.EXE and AUTOCON.DAT are + in the path, the configuration will be updated, and your system + will be rebooted (depending on the current boot choice). + + Alternatively (if you don't want to type the update name), if you + type AUTOCON / ENTER + + AutoCon will pop up a pick list of your configurations, and you + can use the arrow keys to pick a reboot configuration. + + If the update name is the same as the last boot name (see note + above), you will be asked if you really want to do the update. + + + Configuration Inquiry: + Typing AUTOCON /? will cause AutoCon to display the name it + thinks is the current configuration. + + This will be most accurate if Menu mode is active. It should + also be quite accurate if each AUTOEXEC field has the correct + "SET AUTOCON=" command in it. + + If neither of the above applies, it will tell you which command + was last used to configure the AUTOEXEC and CONFIG files, which + may not be the configuration that was used for the last boot. + + + Specific Update: + Typing AUTOCON / ENTER + [e.g., AUTOCON /WIN3 ENTER] + + will cause the named configuration to be updated from the current + C:\AUTOEXEC.BAT and C:\CONFIG.SYS files (or your selected BAT and + SYS filenames). If MENU.CTL is in use, you will be asked if this + is really what you want to do. + + Generic Update: + For those of you who like to live dangerously (all of us from + time to time?), typing "AUTOCON /*" will update the current + configuration (the last one used to reconfigure) from the current + C:\AUTOEXEC.BAT and C:\CONFIG.SYS files (or your selected + filenames). This command will be ignored if the system was + booted with MENU.CTL. + + Equal Check: + Typing "AUTOCON /=" will report on whether or not the current + configuration record is equal to the current record in the + database. + + Batch File Errorlevel Check: + Typing "AUTOCON/@" will set the Errorlevel to + 1 if "" was the one used to boot the system. + This function will set the errorlevel only: there will be nothing + shown on the screen. For full accuracy, see the Environment note + above. + + + + NOTES AND HINTS + + + + Editor Keys: + + I will be enhancing the editor in the next release, so I'm not + going to expend a lot of energy on the Editor Help function in + this one. To find which key does what when you are in the + editor, hit F6 and you will see each action the editor is + capable of and the key assigned to that action. You may also + change the default keys while in this mode. The next release + will add pulldown menus and a much better Help section to the + editor. + + If you are unable to call up the Edit Key function while in the + editor, go back to the main screen, hit F6 to pop up the key + editor, hit END, and you will see a function called Install + Editor Keys. Assign the default F6 key to this function -- or + any other key you like. If you assign another key, the F6 key + will still call up the editor from the main screen, and the + assigned key will work inside the editor. + + + Boot Notes: + + Versions of AutoCon before 2.0 allowed one boot choice for all + configurations. From this version on, you will be able to + select a boot choice for each configuration. + + AutoCon is initially configured with a warm (or soft) reboot. + Some machines have a problem with the warm boot (usually those + with a large hard disk, and a large hard-disk partition + manager) and need a cold boot instead. If you have a reboot + problem, hit F5 and change to a cold boot. This change will be + saved in the AUTOCON.DAT file, and AutoCon will perform a cold + boot (you'll see the memory being checked) in the future. + + Some hardware is so strange (or the software has put the CPU + into such a strange state -- Windows 3 386Enhanced mode) that + even a software cold boot doesn't suffice. If this is the + case, then hit F5 and change to no boot. This last will + require hitting ^AltDel after AutoCon is finished. + + A couple of add-in processor cards (plugging a 286 expansion + card into an XT) come with their own reboot program, and some + people have developed their own reboot utilities to handle + special hardware and/or software needs. For these people, + there is another choice for rebooting. They will need to hit + F5 and change to an External Boot. You will need to enter the + program name that performs your reboot. + + + BAT and SYS Files: + + AutoCon is initially configured to copy the AUTOEXEC and CONFIG + fields to the C drive. For various reasons, some people do + their real boot from a drive other than C. The F8 key will + allow you to change the designated drive (and file name) the + AUTOEXEC field is copied too. The F9 key performs the same + function for the CONFIG field. The new destination files will + be saved to the AUTOCON.DAT file, and used in all future + configurations until you change them again. + + Starting with this version, the BAT and SYS files will be set + with each configuration. Until I make some large changes in + the next version, this will allow you to edit (and keep a + database of) files other than the AUTOEXEC and CONFIG. + + LCD Users: + + If you have a computer with an LCD screen, set your mode to + BW80 (this is mode 2 for you technical people) before starting + AutoCon; that should make the screen show up better. If you + prefer, you can start in color mode, and edit the colors to + something you find suitable. + + Screen Information: + + When you are in the data-entry mode, you have some information + on the screen. The top line has the current date and time, as + well as the name and version of the program. The second line + has the information on the current record, specifically the + record number, and the date and time it was last changed. The + middle of the screen has an area for notes, so that you can + keep track of what this particular record is used for. The + bottom two lines contain help information for the current mode. + + The % on the bottom line of the note frame and of the + edit frame indicates the how full the field is. An empty note + field is 0% full. As you add note characters, the percentage + will increase. (I've had some people ask.) + + The bottom line has some status information about the current + defaults. The first word on the line will be MENU.CTL or + SINGLE. This indicates whether you are using the device driver + to select a configuration during the boot, or whether only a + single configuration is available. + + The second word is either Internal or External; that indicates + whether the internal or the external editor is to be used for + this configuration. The next term is either Flush or No Flush; + that indicates whether or not a Cache Flush command will be + performed for this configuration. The Next word tells what + type of boot will be performed for this configuration; the word + will be either Warm, Cold, None, or External. There may or may + not be a last word. If this record will be one of the default + records used with MENU.CTL, then "Selected" will be written on + the screen. + + + Old Configurations: + If you want to use some configurations you have already + defined, and you are using the internal editor, you may read + them in directly. While in the AUTOEXEC or CONFIG edit mode, + if you hit F5 it will erase the contents of this field, but it + checks with you first. If you then hit ^K ENTER, you will be + given a chance to enter a file name to read into the field. If + you use wildcard notation, AutoCon will pop up a file list for + you to choose from. The selected file name will then be read + into the current field. Do one of the standard exit commands + (AltX, ^K X) and the field now contains the file. + + Do this for each of your current configurations, and you will + now have the convenience of AutoCon with all your standard + configurations. + + Alternately -- especially for those of you using an External + editor -- you may read in a file from the main screen. The ^F8 + key combination will allow you to specify a file name to copy + into the current AUTOEXEC field, and ^F9 performs the same + function for the CONFIG field. + + + LZEXE: + A new program from France has shown up on the scene; it is + called LZEXE. If you use it on AUTOCON.EXE, it will reduce the + size about fifty percent. I am distributing the AUTOCON.EXE + file in the LZEXE format. If you have an XT compatible + machine, then AutoCon may run too slow for you in this format. + If this is the case, you can use the program UNLZEXE to restore + it to its uncompressed format. Both LZEXE and UNLZEXE are + included as a bonus on the registered disk. + + + PKLITE: + Phil Katz has also written a program which will reduce the size + of program files. It is also completely compatible with AutoCon. + + DIET: + There is also a Japanese file compressor called DIET. AutoCon + has also been tested and found compatible with DIET. + CONTACT + + + If you have a problem getting AutoCon set up, or if you find a bug + please let me know immediately. The primary ways to contact me + are to call my office at (916) 623 5045 or (if you have a modem) + my 24 hour BBS at (916) 623 4455. The modem on the BBS is a + 9600 BAUD CompuCom Speedmodem Star. It supports CSP, V32, and V42 + protocols. + + You may also contact me on CompuServe at 72460,3072 or on GEnie + as L.WEAVER1. I check them both at least once a week, and I'm + quite often on CompuServe two or three times a week. + + I'm also open to suggestions for improving AutoCon. A lot of the + current features have been the result of requests made by my + users. + + + + FUTURE + + I think that AutoCon is maturing as a program, and that its + direction is becoming clear. It has changed so much from the + original release that I doubt anyone running version 1.0 would + recognize it as the same program. + + Where is AutoCon going in the future? Well, I have several ideas + in mind for enhancements. You will also have a hand in the + future directions. I have discovered that I can't anticipate all + of your needs. You will have to tell me what changes and + enhancements you would most like to see. + + The biggest set of enhancements I have in mind will concern the + editor. I had a lot of ideas for this release which did not pan + out; you can check the Changes file for the reasons why. I will + add a pulldown menu system to the editor, and give it + split-screen capability. + + I hope to reduce the size as well. Now that AutoCon is approaching + its final form, I can start to optimize a lot of the code in it. + + + LICENSE + + + + This version of AutoCon is NOT public-domain nor free software, + but is being distributed as shareware. + + AUTOCON is copyright (c) 1989-92 by Larry Weaver. + + Non-registered users of this software are granted a limited + license to make an evaluation copy for trial use on a private, + noncommercial basis, for the express purpose of determining + whether AutoCon is suitable for their needs. At the end of this + trial period, you should either register your copy or discontinue + using AutoCon. + + What does all this really mean? If you use this program, then + you should pay for your copy. That way I'll be able to provide + you support and updates, and stay in business. + + An AutoCon registration entitles you to use the program on any + and all computers available to you. + + All users are granted a limited license to copy AutoCon only for + the trial use of others and subject to the above limitations. + This license does NOT include distribution or copying of this + software package + + (a.) in connection with any other product or service, + (b.) for general use within a company or institution, or + (c.) for distribution in modified form, i.e., the file containing + this license information MUST be included, along with the + full AutoCon documentation. + + Operators of electronic bulletin board systems (Sysops) are + encouraged to post AutoCon for downloading by their users, as + long as the above conditions are met. + + If you are the distributor of a public-domain or user-supported + software library, you may be eligible to distribute copies of + AutoCon. You must meet all the above conditions and acquire + written permission from Larry Weaver before doing so, however. + Please telephone or write for details. + + + ASP Requirement + + The program author, Larry Weaver, is an active member of the + Association of Shareware Professionals (ASP). The ASP wants to + make sure that the Shareware principle works for you. If you are + unable to resolve a Shareware-related problem with an ASP member + by contacting that member directly, ASP may be able to help. The + ASP Ombudsman can help you resolve a dispute or problem with an + ASP member, but he does not provide technical support for + members' products. Please write to the ASP Ombudsman at + 545 Grover Road, Muskegon MI 49442, or send a CompuServe message + via EASYPLEX to ASP Ombudsman 70007,3536. + + + DISCLAIMER + + Larry Weaver hereby disclaims all warranties relating to this + product, whether express or implied, including without limitation + any implied warranties of merchantability or fitness for a + particular purpose. Larry Weaver cannot and will not be liable + for any special, incidental, consequential, indirect, or similar + damages due to loss of data or any other reason, even if Larry + Weaver or an authorized Larry Weaver agent has been advised of + the possibility of such damages. In no event shall the liability + for any damages ever exceed the price paid for the license to use + this software, regardless of the form and/or extent of the claim. + The user of this program bears all risk as to the quality and + performance of the software. Use of this program acknowledges + this disclaimer of warranty. + + + + ORDERING INFORMATION + + An AutoCon registration licenses you to use the product on a + regular basis. Users need register only one version of AutoCon; + registration includes licensed use of all upgrades. Registered + users can always get the current version of the program at a + nominal fee ($8.00 as of this writing) by calling or writing + Larry Weaver. Individual registrations for AutoCon cost only + $15. + + CORPORATE SITE LICENSES AND QUANTITY PURCHASES + + All corporate, business, government, or other commercial users of + AutoCon must be registered. A site license is available for a + one-time charge of $120.00 for the first one hundred (or fewer) + users/machines fewer) and $100 for each additional one hundred + (or fewer) users/machines. + + Note: with a site license (if you also purchase the upgrade), + only one copy of the program will be sent. You will be + responsible for distributing additional copies. + + ALL PRICES ARE SUBJECT TO CHANGE WITHOUT NOTICE. + + + Please use the enclosed order form when placing an order, or print + out the file REGISTER.PRN. + + Even if you don't register, how about some feedback? + + You can reach me as + 72460,3072 on CompuServe, or as + L.WEAVER1 on GEnie, + (916) 623-4455 -- Support BBS. + + ------------------- REGISTRATION ---------------------- + + Please support AutoCon! + Thank you for your support. + +Remit To: Larry Weaver + P.O. Box 2639 + Weaverville CA 96093-2639 + + --------------------------- + + You must check one registration option, and one disk option! + + --------------------------- + _ +|_| AutoCon Standard registration ($15.00 -- no disk sent) $______ + _ +|_| AutoCon Site License and Registration (no disk sent) + $120.00 for the first 100 (or fewer) users or machines + 100.00 for each additional 100 (or fewer) users or machines $______ + + --------------------------- + _ +|_| AutoCon Upgrade to the newest version ($8.00; $10.00 foreign) $______ + Registered users only + _ +|_| Subscription plan for REGISTERED users ($21.00; $26.00 foreign) $______ + (Receive the next three updates of AutoCon, as they + become available. This fee is in addition to the + $15.00 or $120.00 registration.) + + --------------------------- + _ +|_| Printed Manual ($8.00) $______ + If you desire, I will print out the AUTOCON.DOC file and + send it to you. You can achieve the same results by printing + it out yourself, but several people seem to want this. + + --------------------------- + +"Foreign" means outside the USA and Canada; the extra charge covers postage. + _ _ +Payment by: |_| Check or |_| Money Order enclosed. + +TOTAL in USA Funds. $______ + Foreign checks are acceptable if they have the US Federal Reserve + Routing Number on them, use the current exchange rate. + _ _ +Disk Type: |_| 5 1/4" (normally sent); |_| 3 1/2" required + +Name ___________________________________________________________________ + +Address ___________________________________________________________________ + + ___________________________________________________________________ + + ___________________________________________________________________ + + + Day Phone: _________________________ Eve: ______________________ + + Compuserve ID: _____________________ + + _ + Invoice Required |_| P. O. Number: ______________________ + + ------------------------ User comments ------------------------- + I acquired AutoCon V2.0g from + [ ] - Friend [ ] - Software product + [ ] - Computer Club [ ] - Computer Store + [ ] - Data Base Service [ ] - Support BBS + [ ] - Electronic BBS - Please give phone no. _____________ + [ ] - Other (please specify) ___________________________ + + I would also appreciate any input you would care to provide + concerning AutoCon. If you have any ideas or comments which would + make AutoCon a better program, please let me know. + + I value your comments! + + Comments and/or suggestions: + ________________________________________________________________ + + ________________________________________________________________ + + ________________________________________________________________ + + ________________________________________________________________ + + ________________________________________________________________ + + ________________________________________________________________ + + ________________________________________________________________ diff --git a/Linux-0.95/INSTALL/autocn/AUTOCON.EXE b/Linux-0.95/INSTALL/autocn/AUTOCON.EXE new file mode 100644 index 00000000..9dfa0b7f Binary files /dev/null and b/Linux-0.95/INSTALL/autocn/AUTOCON.EXE differ diff --git a/Linux-0.95/INSTALL/autocn/AUTOCON.HLP b/Linux-0.95/INSTALL/autocn/AUTOCON.HLP new file mode 100644 index 00000000..705e7e33 Binary files /dev/null and b/Linux-0.95/INSTALL/autocn/AUTOCON.HLP differ diff --git a/Linux-0.95/INSTALL/autocn/CACHE b/Linux-0.95/INSTALL/autocn/CACHE new file mode 100644 index 00000000..925888db --- /dev/null +++ b/Linux-0.95/INSTALL/autocn/CACHE @@ -0,0 +1,34 @@ + +If you are running a Cache program, and do not have it set to write +through, then (if you have Autocon set for a Warm or Cold boot -- and +probably External) you must configure Autocon to "Flush" your cache. +Hit the key, and put in the command string that causes your cache +to flush. The command should be listed in the documentation for your +Cache program. Autocon will then save the information, and perform a +"Flush" before each reboot. + +If you are not sure if your Cache is set to "write through", please +configure Autocon to do the "Flush", just to be on the safe side. + +The symptoms of a cache problem is that the Autoexec and Config files do +not get updated, and/or any edited Autocon configurations do not get +saved. In the worst case, the Autocon.Dat file will get corrupted, and +your screen colors will disappear (screen will be blank when you start +AutoCon). + +Setting Autocon up to do the "Flush" will remove the problems. + +Some Flush commands that I know are: + + PC-KWIK - SUPERPCK /F + PC-CACHE - PC-CACHE /FLUSH + FLASH - FLASH /F? + HYPERDISK - HYPERDK W + SMARTDRV - SMARTDRV /C (new ver with WINDOWS 3.1) + + + +Sorry for any inconvenience, + + + -Larry Weaver diff --git a/Linux-0.95/INSTALL/autocn/CHANGES b/Linux-0.95/INSTALL/autocn/CHANGES new file mode 100644 index 00000000..03775362 --- /dev/null +++ b/Linux-0.95/INSTALL/autocn/CHANGES @@ -0,0 +1,61 @@ + + CHANGES + + I don't know if you read the changes file in the previous version, + so I will summarize it. I sold my home in Santa Barbara, and moved + to a small town in Northern California to concentrate on writing + shareware full time. Well (you may ask), how's it going. + + Since my program was reviewed on page 50 in the Nov. 13, 1990 issue + of PC Magazine, registrations have increased significantly. + Appearantly a lot of people read (and pay attention to) PC + Magazine. Site registrations have really increased, and I now have + some Fortune 50 customers. Banks, however, make up the bulk of + the Site Licensees. + + I ran into a few tax problems (it was either pay Uncle a lot of + money, or put a lot of money into my house), so I've been + consulting pretty heavily the last year and doing major + reconstruction to my house. I think I am finally through with any + big consulting jobs (and with rebuilding my house), so now AutoCon + will be getting a lot more attention. + + This is still not the release I had planned (it will probably show + up some time around July), but one of my competitors was on + Compuserve saying how much better he was than I because his program + could handle DOS 5.0's HIGH and UMB flags. I decided I needed to + add this capability to AutoCon and get out a new release before he + could cause any more problems. So with this release, AutoCon will + handle both MSDOS 5.0's HIGH and UMB flags, and it is compatible + with DRDOS which is one up on my competitor. + + The 2.1 release of AutoCon will have a lot more editor + enhancements. I'm planning pull down menus (similar to the front + screen), and a split screen capability. I also intend to allow + Search/Replace operations to go automatically through all + configurations. I will also be able to use the screen size in + effect when AutoCon is started, instead of switching everything to + the 80X25 mode. + + I have a support BBS online and functional. The number is (916) + 623 4455, and it is in operation 24 hours a day. It has a 9600+ + BAUD modem that is CompuCom CSP, V32, and V42 compatible (of course + it connects just fine at 2400 BAUD). The main function + of the BBS is (of course ) AutoCon support. If it gets busy + enough, it will grow into a full multi-line BBS. As a consequence + there are several megabytes of downloadable files on it, always + including the latest shareware release of AutoCon. I will also set + up a section for a group of Beta testers, so let me know if you are + interested in becomming one. I see several enhancements in + AutoCons future, as well as a few other programs that I have in + mind. + + This is my first BBS and I'm sure there will be will be some + growing pains, so please bear with me. + + I love the place I've moved to and I thank you very much for the + support you have given to AUTOCON, and for giving me the incentive + to change careers. + + + -Larry Weaver diff --git a/Linux-0.95/INSTALL/autocn/FILE_ID.DIZ b/Linux-0.95/INSTALL/autocn/FILE_ID.DIZ new file mode 100644 index 00000000..e8745208 --- /dev/null +++ b/Linux-0.95/INSTALL/autocn/FILE_ID.DIZ @@ -0,0 +1,8 @@ +AutoCon V2.0g is a database manager for +Autoexec and Config Files. Allows up to +50 configurations, and makes switching +between them easy. Run full interactive +(editor, mouse, menus, context sensitive +help, etc.) or command line. MENU.CTL +device driver can setup menu of +configurations during boot. (ASP) diff --git a/Linux-0.95/INSTALL/autocn/KEY.TXT b/Linux-0.95/INSTALL/autocn/KEY.TXT new file mode 100644 index 00000000..6d8bf000 --- /dev/null +++ b/Linux-0.95/INSTALL/autocn/KEY.TXT @@ -0,0 +1,175 @@ +The following is a list of the all of the editor functions, and the +default key assignments. + + CURSOR MOVEMENT: + , + Cursor left one character. + + , + Cursor right one character. + + , + Cursor left one word. A 'word' is a series of non-separator + characters followed by one or more of the following : + ' ', ';', '/', '=' + + , + Cursor right one word. + + , + Cursor to beginning of line. + + , + Cursor to end of line. + + , + Cursor up one line. + + , + Cursor down one line. + + + Scroll display up one line. + + + Scroll display down one line. + + , + Scroll display up one page. + + , + Scroll display down one page. + + , + Move cursor to top of edit window. + + , + Move cursor to bottom of edit window. + + , + Move cursor to beginning of field. + + , + Move cursor to end of field. + + , + Move the cursor to the next tab stop. + + + Move the cursor to the position indicated by the mouse. + + DELETE FUNCTIONS: + , + Delete character at cursor. + + , , + Delete character to left of cursor. + + + Delete current line. + + + Delete from cursor to end of line. + + + Delete word to right of cursor. + + NEW LINE: + , + Start a new line. + + + Split the current line at the cursor. + + DEFAULT CONTROLS: + + Insert control character. For example, to insert a ^G, you + would enter . + + + Toggle insert mode on and off. Fat cursor indicates insert + mode; thin cursor indicates overtype mode. + + + + Toggle auto-indent mode. In auto-indent mode, pressing + in insert mode causes the new line to have the same + indentation as the previous line. Auto-indent also affects + the way that text is formatted when word wrap occurs. + + + Reformat the current paragraph. Use with caution. + + + Reformat the entire field. Use this command with caution. + + + Restore original contents of the line and continue editing. + + SAVE COMMANDS: + , , , , + + Quit editing and abandon changes (With Question). + + , + Save the data, but continue editing. + + , , , + Save the data (if modified), and quit editing. + + BLOCK COMMANDS: + , , + Begin a block mark. End a block mark. + + + Copy a marked block. Move a marked block. + + + Delete a marked block. Delete Contents of Entire field. + +

+ Put marked block in buffer. Copy cUt buffer to Fieeld. + Allows moving data between records. + + + Write the Marked Block to the selected file name. + + + Read the selected file name into the edit field. You can + popup a file list and use a point and shoot select + + + SEARCH COMMANDS: + + Pops up a window for you to enter a string of text to search for. + The string remains valid across all records until it is changed with + another search function. + + + Pops up a window for you to enter a string of text to search for, + then pops up a window for you to enter a string of text to replace + the search string with. You will be asked to confirm the + replacement. The strings remain valid across all records until it + is changed with another search function. + + + Repeats the last Search(/Replace) function without going through the + exercise of entering new strings. + + MISCELLANEOUS COMMANDS: + + , + Help. This command invokes the help routine for this topic + if it exists. Otherwise it does nothing. + + + Pops up a key edit window to allow chaging all of the editor key + assignments. + + + Creates a "SET AUTOCON=" command for the + Autoexec field. If each Autoexec has the correct one, the name of + the boot configuration will be in the environment. + + , , + Changes the keys assigned to change the colors used in the editor. diff --git a/Linux-0.95/INSTALL/autocn/MENU.CTL b/Linux-0.95/INSTALL/autocn/MENU.CTL new file mode 100644 index 00000000..34f26180 Binary files /dev/null and b/Linux-0.95/INSTALL/autocn/MENU.CTL differ diff --git a/Linux-0.95/INSTALL/autocn/MENUNUM.COM b/Linux-0.95/INSTALL/autocn/MENUNUM.COM new file mode 100644 index 00000000..c618398c Binary files /dev/null and b/Linux-0.95/INSTALL/autocn/MENUNUM.COM differ diff --git a/Linux-0.95/INSTALL/autocn/REGISTER.PRN b/Linux-0.95/INSTALL/autocn/REGISTER.PRN new file mode 100644 index 00000000..9cd133cd --- /dev/null +++ b/Linux-0.95/INSTALL/autocn/REGISTER.PRN @@ -0,0 +1,94 @@ + ------------------- REGISTRATION ---------------------- + + Please support AutoCon! + Thank you for your support. + +Remit To: Larry Weaver + P.O. Box 2639 + Weaverville CA 96093-2639 + + --------------------------- + + You must check one registration option, and one disk option! + + --------------------------- + _ +|_| AutoCon Standard registration ($15.00 -- no disk sent) $______ + _ +|_| AutoCon Site License and Registration (no disk sent) + $120.00 for the first 100 (or fewer) users or machines + 100.00 for each additional 100 (or fewer) users or machines $______ + + --------------------------- + _ +|_| AutoCon Upgrade to the newest version ($8.00; $10.00 foreign) $______ + Registered users only + _ +|_| Subscription plan for REGISTERED users ($21.00; $26.00 foreign) $______ + (Receive the next three updates of AutoCon, as they + become available. This fee is in addition to the + $15.00 or $120.00 registration.) + + --------------------------- + _ +|_| Printed Manual ($8.00) $______ + If you desire, I will print out the AUTOCON.DOC file and + send it to you. You can achieve the same results by printing + it out yourself, but several people seem to want this. + + --------------------------- + +"Foreign" means outside the USA and Canada; the extra charge covers postage. + _ _ +Payment by: |_| Check or |_| Money Order enclosed. + +TOTAL in USA Funds. $______ + Foreign checks are acceptable if they have the US Federal Reserve + Routing Number on them, use the current exchange rate. + _ _ +Disk Type: |_| 5 1/4" (normally sent); |_| 3 1/2" required + +Name ___________________________________________________________________ + +Address ___________________________________________________________________ + + ___________________________________________________________________ + + ___________________________________________________________________ + + + Day Phone: _________________________ Eve: ______________________ + + Compuserve ID: _____________________ + + _ + Invoice Required |_| P. O. Number: ______________________ + + ------------------------ User comments ------------------------- + I acquired AutoCon V2.0g from + [ ] - Friend [ ] - Software product + [ ] - Computer Club [ ] - Computer Store + [ ] - Data Base Service [ ] - Support BBS + [ ] - Electronic BBS - Please give phone no. _____________ + [ ] - Other (please specify) ___________________________ + + I would also appreciate any input you would care to provide + concerning AutoCon. If you have any ideas or comments which would + make AutoCon a better program, please let me know. + + I value your comments! + + Comments and/or suggestions: + ________________________________________________________________ + + ________________________________________________________________ + + ________________________________________________________________ + + ________________________________________________________________ + + ________________________________________________________________ + + ________________________________________________________________ + + ________________________________________________________________ diff --git a/Linux-0.95/INSTALL/autocn/WHATSNEW b/Linux-0.95/INSTALL/autocn/WHATSNEW new file mode 100644 index 00000000..38116aa8 --- /dev/null +++ b/Linux-0.95/INSTALL/autocn/WHATSNEW @@ -0,0 +1,441 @@ +Version 2.0g + I still had complaints about people seeing Echo Off in the Autoexec + Bat file, so now if you have a DOS higher than 3.2, it will start + with @Echo off. + + If you are using DOS 5.0, A DOS=HIGH,NOUMB line will be appended to + the bottom of the Autoexec.bat file, and you will have to put a + DOS=LOW (and/ or a DOS=UMB) in the configurations you need them in. + Menu.Ctl will control the flags. + + If you are using DRDOS, Menu.Ctl will now work with it as well as + MSDOS. + + I've changed the way I load configurations, so you will be able to + run AutoCon with less memory, and there is no longer a 6K or 2K + limit on the Autoexec and Config fields. + + Each configuration now has the names of the files that the field is + written to. (I've had several requests for this one.) + + The help screen colors are now installable. + + The MENU.CTL interface has been rewritten to show up more distinctly + when booting. I had several complaints that it was easy to miss. + It will now put up some distinctive boxex, and show up in color if + you have a color monitor. The colors are installable from AutoCon. + + Each configuration now has the names of the files that the field is written + to. (I've had several requests for this one.) + + You can tell AutoCon not to restore the screen on exit (eliminates the + need for AutoConx.exe. + + +Version 2.0e (mainly bug fix) + In Single mode if the Enviornment name wasn't set (AltE in the + editor) AutoCon could get the wrong cache 'Flush' information. This + is fixed, but I highly reccommend setting the Autocon Environment + variable if you are using Single mode. + + If an external editor were being used, and the Autocon or Config + field size got too large, the AutoCon.Dat file could get messed up - + fixed. + + Several people have complained that 4K and 2K is not large enough + for the Autoexec and Config fields, so I'm pushing the size up to 6K + and 4K. Please note that this adds 4K/configuration to AutoCon's + memory requirements. + + There are two extra EXE files on the BBS. AutoCons.exe will still + use 4K and 2K for those needing the smaller memory requirements. + + AutoConx.exe will not restore the screen when it exits. Try this if + you lose the cursor or the screen blanks out when you exit (I've had + two complaints about this). + +Version 2.0d (bug fix) + If AutoCon followed an "ECHO OFF" and a "CLS" statement in a batch + file, the screen could get slightly messed up - fixed. + +Version 2.0c (bug fix) + The user modified colors were getting lost if a reboot was performed + from the command line - fixed. + +Version 2.0b (bug fix) + + MENU.CTL had a problem with the name of the eighth configuration, + which is now fixed. It also had a tendency to leave menu choice 2 + in the hi-lite mode, also fixed. + + Several people complained about seeing the Errorlevel statements in + the AUTOEXEC.BAT during the boot process. AUTOEXEC.BAT files will + now start with ECHO OFF as the first statement if you choose the + MENU.CTL option. + + Version 2.0 would allow you to choose more than the eight default + configurations. This is no longer allowed. + + Version 2.0 had a problem writing the AUTOEXEC.BAT file for the Menu + mode if the Autoexec fields didn't end in a Carriage Return. This + is now fixed. + + +Version 2.0 + + + I'm jumping the version number from 1.4 to 2.0 for this release. + The reason is that AutoCon's capability has changed so much in this + release that I think it warrants a Major revision number change. + + The major change is the inclusion of two new files. These are + MENU.CTL and MENUNUM.COM. Menu.Ctl is a device driver that can + disable commands in the CONFIG.SYS file. MenuNum.Com is a file that + will ask the portion of Menu.Ctl that stays resident which + configuration was chosen, and set the DOS ERRORLEVEL to that number. + This allows setting up menu choices in the AUTOEXEC.BAT file to + match the choice made from the CONFIG.SYS file. Together these two + files allow you to choose a system configuration from a menu of + configurations during the boot process itself. + + AutoCon will handle all of the interface details to these two + commands for you, and allow you to return to a "Normal" system + configuration in just a couple of keystrokes. This will allow you + to run programs like "Optimize" from Quarterdeck. + + + There is a pull-down menu system available on the main screen. Each + item on the menu has a context sensitive help entry. This should + make it very easy to get AutoCon up and running the first time, and + allow you to look up those commands you can't remember the + keystrokes for. + + + There are two new command line options. If you enter + + AutoCon / + + on the command line, a window of your configurations will pop up + asking you to choose which configuration you wish to use to reboot + the system. This is equivalent to the "AutoCon , + except that AutoCon lets you choose the name from a pick list. + + The second new command is + + AutoCon /@ + + where is the name shown on the main screen for + each configuration. If the name matches the configuration that was + used for the boot process, the DOS errorlevel will be set to 1. It + will be set to 0 otherwise. For this function to work correctly, + you need to boot up with Menu.Ctl, or assure that each Autoexec + field has the correct name assigned with a SET command. See the new + "Put Name in Environment" editor function defined below. + + + The internal editor has a few new capabilities. In order to access + most them you will have to edit your keystrokes (using the F6 key). + The block operations are no longer constrained to full lines. The + default keys for reformating were removed. You may reassign them. + + "Search Function" (default assigned to ^Q^F) allows you to search + the text for a specified string of text. The string is active for + the entire AutoCon session, and will be the same across records. + + "Search/Replace Function" (default assigned to ^Q^A) allows you to + search the text for a specified string of text, and relpace it + with another string of text. You will be asked to confirm the + replacement. + + "Repeat Search Function" (default assigned to ^L) This will + repeat the last Search, or Search/Replace that was performed. The + informations is retained during the AutoCon session, and will be + the same across records. + + "Install Editor Keys" (default assigned to F6) allows you to + change the editor keys during an edit session. + + "Put Name in Environment" (default assigned to AltE) will put a + SET command in your edit field. This will guarantee that the + configuration you are editing has its name placed correctly in the + environment. AutoCon will use this name for various command line + functions. + + "Change (Text - AltF6, Block - AltF7, Control Char - AltF8) + Attribute" will allow you to change the keys that call up the + editor color installation windows. + + "View Last Dos Screen" (default assigned to AltV) allows you to + see the DOS screen as it was when AutoCOn was started. Could be + useful if the reason your changing a configuration is shown there. + + + By March 1, 1991 I will have a support BBS in place operating 24 + hours a day. The number will be (916) 623 4455. + + +Version 1.4 + + One of the WhatsNews has to do with me, I am now a member of the ASP + (Association of ShareWare Professionals). The rest of the WhatsNews + all concern changes (and additions) to the program. + + You now have the option to use the built in editor to edit the + Autoexec and Config fields, or to install an external editor to do + the job. will pop up a window for you to enter an external + editor's file name. The Path will be checked for the entered file + name, and if found, it will be used to edit the Autoexec and Config + fields in the future. For more info, see the "Installing External + Editor" section of AUTOCON.DOC. + + From the command line, typing will check the Autoexec + and Config fields of the current configuration record against the + file contents of the current Configuration files (usually + C:\AUTOEXEC.BAT and C:\CONFIG.SYS). The results of the comparison + will be shown on the screen. SPECIAL NOTE! - the configuration will + need to have been saved with the 1.4 version of AUTOCON. + + From the command line, typing will update the Autoexec + and Config fields of the current configuration record from the file + contents of the current Configuration files (usually C:\AUTOEXEC.BAT + and C:\CONFIG.SYS). You might want to be a little careful with this + one. + + The internal editor has a few new capabilities. In order to access + them, you will probably have to edit your keystrokes (using the + key). The new commands are "Split Line", "Cut the marked block", + and "Paste the last Cut block". These commands will be a little + more convenient than the current "Write marked block" and "Read + marked block" file commands. + + "Split Line" (default assigned to key) splits the current + line at the cursor, leaving the cursor where it is, and moving the + rest of the line down to the next line. + + "Cut the marked block" (default assigned to key + combination) will put the current marked block into a text buffer. + "Paste the last Cut block" (default assigned to

key + combination) will paste the contents of the cut buffer to the + current cursor location. This command can be used to move the + data in the same record, or across records. After a cUt, the data + will stay in the buffer until a new cUt is performed, or AUTOCON + is exited. + + Formerly the editor only recognized a ' ' (space) as a word mark + (for , , , etc.). This has been enhanced + to also recognize the following characters as word marks : + '/', ';', and '='. + + Line length was increased to 254 for those long path names (and + any other long lines needed). This necessitated removing the + word-wrap capability while editing the Autoexec and Config + fields (I don't think this will be a hardship, you probably don't + want to word-wrap the lines in your Autoexec and Config files + anyway). Word-wrap is still used in the Notes field, but please + don't enter a line longer than 127 characters in there. + + + A couple of functions were also added to the Interactive Mode. + + will pop-up a pick list of the current configuration + records, and allow you to select one. The contents of the + Autoexec and Config fields of the selected configuration record + will be copied to the current configuration record. Be careful + with this one, there is NO "Undo" command. You can always + use ESC to get out of the pick list without doing a copy. + + will now show the Dos screen as it was when Autocon was + started. + + will check the Autoexec and Config fields of the current + configuration record against the contents of the current + configuration files (C:\AUTOEXEC.BAT and C:\CONFIG.SYS, unless you + have changed them with or keys). SPECIAL NOTE! - the + configuration will need to have been saved with the 1.4 version of + AUTOCON. + + All of the color changes now show up instantly (you previously had + to wait till the next time Autocon was executed to see some of the + color changes). + + ESC is no longer accepted as a "Yes" answer (there were a lot of + complaints on this one). A "Yes" answer now requires a or + key (accept default). + + There are a few cosmetic changes on the screens (all in response to + comments by users). I won't take the space to list each one. + + There are a couple more entrys on the help screen, and (I hope) the + entries are arranged in a little more logical fashion. + + UltraVision : Autocon is now UltraVision "Aware". Autocon will + detect if UltraVision is installed and active. If it is, Autocon + will use UltraVision to switch modes, and restore screens (in other + words, Autocon won't mess up your screen). + + Windows Problems : After spending a very unproductive day on the + phone with Microsoft, I decided to add another boot type option to + Autocon. Several people use Autocon to reconfigure in and out of + Windows. When Windows is running in 386 enhanced mode, a software + boot (usually) doesn't work. Microsoft's recommendation : "Never + reboot while running Windows". They say that this may trash hard + disks and worse (I'm not sure what could be "worse" than trashing a + hard disk). I don't know about you, but I've had to reboot out of + Windows several times. I know it's probably not a good idea, but + there are times it should be quite safe (and times when it is forced + upon us). Anyway, they say that is no way they are aware of to + ensure that a software reboot will work. + Therefore : + + You may now select (N)one as an alternate boot type (using the + key). If you select (N)one, Autocon will now reconfigure the + files, but will not attempt a reboot. Now you may run Autocon + under Windows, and after the system files are reconfigured, you + can hit the dreaded CtrlAltDel key combination. + + By the way, I'm not much of an artist, so if someone (out of the + goodness of their hearts) designs a nice Icon for Autocon, I would + appreciate them sending me a copy. + + + A potentially nasty bug was squashed. Since I never received a + complaint on this one, I assume that I was the only one "bit". If + your current configuration record was the last one, and you deleted + it, Autocon tried to find it again the next time it was started. + This could lead to bizarre behavior (a messed up pointer for those + technical people). If the current record number is larger than the + max record number, it will now be adjusted (with appropriate warning + message). It will still be pointing to the wrong record, but it + will behave in a known fashion. + + ______________________________________________________________________ + +Version 1.3a + + There are a few bug fixes, and a couple of enhancements in this + version. If you used F2 to save changes in the previous versions, + when you hit ESC to exit it would issue a warning that the changes + were about to be lost, this has been corrected. + + AUTOCON will now attempt to detect and restore the EGA/VGA (45/50) + small character mode upon exit. + + After updating the configuration with 1.3a, when AUTOCON is started + in the interactive mode, it will default to the configuration used + in the last update. + + On the command line if you type the name of the current + configuration will be displayed (Note: you must have saved a + configuration with V1.3a first). + + If you are in the full screen entry mode, hitting will update + the Autoexec and Config fields in the current record from the + current AUTOEXEC.BAT and CONFIG.SYS files. This saves going into + each of the two fields and doing a <^KR> . + + From the command line, typing AUTOCON followed by a / and the name + of a configuration (e.g. ) will cause that + configuration to have it's Autoexec and Config fields updated from + the current AUTOEXEC.BAT and CONFIG.SYS files. + + There was a bug in V1.3 that caused AUTOCON to have a problem with + reading files that were not terminated with ^Z. If you got an + "Edit Buffer Full" message when you tried to edit a field that you + know wasn't too big, then you were bitten by this bug. This is + fixed in 1.3a. + + If you were in one of the fields and issued an <^KW> (block save) + and didn't have a marked block, you were not given an error message + in previous versions. This is fixed in 1.3a. + + The help screen displayed in a color change window was the one for + changing the editor keystrokes. This is fixed in 1.3a. + + ______________________________________________________________________ + +Version 1.3 + + There are several changes in this version. If you have added + several extra configurations that you no longer need, the + key will delete the current configuration (you can't delete record + one, nor can you go below five records). + + You can change the keystrokes used by the built in editor. Hitting + the key in the main menu will pop up a key editor which will + allow changing the actions of all of the control keys used in the + editor. + + You can change the colors used by AUTOCON. Hitting the key in + combination with the function keys will allow customization of most + of the colors. The use of each key is detailed in the pop-up help. + + The DAT file format for 1.3 is quite different than the one for 1.2. + The white space has been eliminated, and as a consequence it is + significantly smaller (mine are about 1/4 the previous size). The + first time you run 1.3 it will change the format, and the DAT file + will no longer be compatible with 1.2. You may want to make a copy + of AUTOCON.DAT (just to be on the safe side) before running 1.3. + + + ______________________________________________________________________ + +Version 1.2d keeps current file attributes + + A request was made to update the Autoexec and Config files, but to + not change their current attributes (system, read only, hidden, + etc.). Therefore AUTOCON now reads the current file attributes of + Autoexec.Bat and Config.Sys before updating them, and restores the + attributes after the update. + + + ______________________________________________________________________ + +Version 1.2c adds a boot type select. + + Some computers have trouble with the warm boot that AUTOCON was + originally configured with. These seem to mainly be machines with + large hard disks, and a large hard disk manager. The key now + allows you to change the boot type from warm to cold to get around + this problem. + + + ______________________________________________________________________ + +Version 1.2a is a bug fix. + + AUTOCON didn't recognize more than three configurations from the + command line. + + +Version 1.2 is a bug fix. + + When you attempted to read in your old configuration files to the + AUTOEXEC and CONFIG fields, it always defaulted to C:\AUTOEXEC.BAT + an C:\CONFIG.SYS no matter what files you had selected. The read + file option now works correctly. + + + ______________________________________________________________________ + +Version 1.1 charges are as follows. + + 1. AUTOCON now does a Reboot when a reconfiguration is done from the + command line. + + 2. AUTOCON now handles up to 50 configurations (originally only 5). + + 3. You can now read any file into an AUTOEXEC or CONFIG edit field + (allows you to use your old configurations). + + 4. The On-line Help has been updated/enhanced. + + 5. The Doc file has been enhanced (left out a few things the first + time). + + 6. Allows you the choice of a Reboot when reconfiguring in the data + entry mode. + + 7. Hopefully a better choice of colors on an LCD screen. If you have + an LCD, you need to have your mode set to BW80 (2). + + diff --git a/Linux-0.95/INSTALL/autocn2g.zip b/Linux-0.95/INSTALL/autocn2g.zip new file mode 100644 index 00000000..3b0c1375 Binary files /dev/null and b/Linux-0.95/INSTALL/autocn2g.zip differ diff --git a/Linux-0.95/INSTALL/bootlin4.zip b/Linux-0.95/INSTALL/bootlin4.zip new file mode 100644 index 00000000..4fcd648d Binary files /dev/null and b/Linux-0.95/INSTALL/bootlin4.zip differ diff --git a/Linux-0.95/INSTALL/clock.tar.Z b/Linux-0.95/INSTALL/clock.tar.Z new file mode 100644 index 00000000..36739c6a Binary files /dev/null and b/Linux-0.95/INSTALL/clock.tar.Z differ diff --git a/Linux-0.95/INSTALL/pboot.exe b/Linux-0.95/INSTALL/pboot.exe new file mode 100644 index 00000000..835ebaa1 Binary files /dev/null and b/Linux-0.95/INSTALL/pboot.exe differ diff --git a/Linux-0.95/INSTALL/pboot.zip b/Linux-0.95/INSTALL/pboot.zip new file mode 100644 index 00000000..8584490e Binary files /dev/null and b/Linux-0.95/INSTALL/pboot.zip differ diff --git a/Linux-0.95/INSTALL/pfdisk/MAKE_TCC.BAT b/Linux-0.95/INSTALL/pfdisk/MAKE_TCC.BAT new file mode 100644 index 00000000..8466b230 --- /dev/null +++ b/Linux-0.95/INSTALL/pfdisk/MAKE_TCC.BAT @@ -0,0 +1,3 @@ +@echo This batch file uses Turbo C to build pfdisk.exe +@echo Note that only SMALL model has been tested... +tcc -v- -epfdisk.exe pfdiskaz.c syscodes.c s_msdos.c diff --git a/Linux-0.95/INSTALL/pfdisk/PFDISK.DOC b/Linux-0.95/INSTALL/pfdisk/PFDISK.DOC new file mode 100644 index 00000000..10fc307f --- /dev/null +++ b/Linux-0.95/INSTALL/pfdisk/PFDISK.DOC @@ -0,0 +1,264 @@ + + + + + +PFDISK(8) MAINTENANCE COMMANDS PFDISK(8) + + + + + +NAME + pfdisk - partition fixed disk + +SYNOPSIS + pfdisk device + +DESCRIPTION + pfdisk partitions the fixed disk identified as device into (at + most) four parts, each of which may be independently loaded with + an operating system. The actual name of device depends on the + operating system in use. For ESIX (System V/386) the device + name is either "/dev/rdsk/0s0" or "/dev/rdsk/1s0". For Minix, + it is "/dev/hd0" or "/dev/hd5". For MS-DOS it is a single digit + (zero or one). + + pfdisk reads the hard disk partition table from block zero of + device into memory and allows the user to examine, modify, or + save the partition table. A regular file may be used instead of + a real device for testing purposes, though the device geometry + must be specified manually, and some systems will requrire a + file-name argument with the "R" and "W" commands (DOS, ESIX). + + The partition table on device is NOT modified unless the write + command (W) is used with no argument. + +USAGE + Commands + All pfdisk commands consist of a command word followed by + optional blank-separated command arguments. Note that only the + first letter of a command word is significant (except for "wq" + and "q!"). All command letters are accepted in either upper or + lower case. Numeric arguments are specified using C syntax. + Extra arguments are silently ignored. + + The commands are: + + ? Prints a command summary (help). + + 1 sys_id first last sys_name + Set the partition table entry for part one, using: + sys_id as its system ID code, first as the lowest num- + bered cylinder it uses, last as the highest numbered + cylinder it uses, and sys_name (optional) as the system + name (in the menu name table). + + 2|3|4 sys-id first last sys-name + Similar to 1 but sets partition two, three, or four, + respectively. + + + + + +Release 1.3 Last change: Oct 1990 1 + + + + + + +PFDISK(8) MAINTENANCE COMMANDS PFDISK(8) + + + + + + A number + Mark partition number as active (so it will be used for + booting). If number is zero, no partition will be + active. + + G cylinders heads sectors + Inform pfdisk what the geometry of the device is. + + I Print a summary of the known ID codes. + + L List the partition table. See Output Format below. + + Q Quit without saving. If the memory copy of the parti- + tion table was modified, a warning will be issued and + the command ignored. + + Q! Quit, even if the memory copy of the partition table was + not saved. + + R file-name + Read boot sector from file-name (if given) otherwise + read from device. + + W file-name + Write boot sector to file-name. (if given) otherwise + write to device. + + WQ Same as "write" followed by "quit". + + # This line is a comment (to be ignored). + + Output Format + Here is a sample of the output from the L command: + + # Partition table on device: /dev/rdsk/0s0 + geometry 1222 15 34 (cyls heads sectors) + # ID First(cyl) Last(cyl) Name # start, length (sectors) + 1 4 0 127 MS-LOSS # 34, 65246 + 2 129 128 255 Minix # 65280, 65280 + 3 0 0 0 # 0, 0 + 4 99 256 1220 ESIX # 130560, 492150 + # note: last(4): phys=(1023,14,34) logical=(1220,14,34) + active: 4 + + This output format is carefully constructed so that it may be + saved in a file (by redirecting standard output) and later used + as input (by redirecting standard input). On a UNIX system, one + can save this output using the command: + + + + + +Release 1.3 Last change: Oct 1990 2 + + + + + + +PFDISK(8) MAINTENANCE COMMANDS PFDISK(8) + + + + + + (echo L) | pfdisk device-name > save-file + + save-file is a complete record of the partition table. On a + UNIX system, one could use save-file to re-initialize the parti- + tion table using the command: + + (cat save-file ; echo wq) | pfdisk device-name + + Consistency of each partition table entry is checked while the + table is listed. Any inconsistencies discovered are reported in + a commentary note as shown above. + + Physical vs. Logical + Each partition table entry has both "physical" and a "logical" + fields. The physical fields specify the lowest and highest + cylinder,head,sector combinations to be used in that partition. + The logical start field has the total number of sectors which + precede this partition, and the logical length field has the + total number of sectors contained in this partition. These + fields should be self consistent unless the disk has more than + 1024 cylinders. + + The physical cylinder fields are only ten-bits wide so the con- + tents are limited to 1023. The logical sector fields are 32 bits + wide and always show the true logical beginning and length of + the partition. Generally, the physical start field is used only + to locate the secondary boot sector, and the logical start and + length fields are used to actually delimit the partition used by + a particular system. + + Partition Names + The Name field in the partition table is treated specially if + the bootmenu program is installed in the primary boot sector. + (See the file bootmenu.doc for more information.) pfdisk can + recognize the name table used by bootmenu and will show the + actual names present in that name table. If any other boot pro- + gram is used then the Name field reflects the result of a + table-lookup of the system ID. + + If you provide a name when setting any partition entry, the + boot-sector is marked as using a name table, so that on subse- + quent uses of pfdisk you will see the partition names you have + specified. + + Boot program replacement + You can replace the boot program in your boot sector without + affecting the partition table by using pfdisk as follows. + First, (as always) save a copy of the current boot sector (on a + + + + + +Release 1.3 Last change: Oct 1990 3 + + + + + + +PFDISK(8) MAINTENANCE COMMANDS PFDISK(8) + + + + + + floppy) using the "W file" command. Then, use the "R file" com- + mand to read the new boot program. If the boot program read in + is less than 446 bytes long, the partition table will be + unchanged. + + Unlike the DOS or UNIX fdisk programs, pfdisk has NO boot pro- + gram compiled into its executable image. If you wish to use + pfdisk to partition a newly formatted hard disk, you must have a + boot program image available to read in using the "r file" com- + mand. Two boot programs, "bootmenu.bin" and "bootauto.bin" are + distributed with pfdisk and should be found with its source + files. See the file bootmenu.doc for further information about + these boot programs. + +AUTHOR + Gordon W. Ross + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Release 1.3 Last change: Oct 1990 4 + diff --git a/Linux-0.95/INSTALL/pfdisk/PFDISK.EXE b/Linux-0.95/INSTALL/pfdisk/PFDISK.EXE new file mode 100644 index 00000000..2742a2f4 Binary files /dev/null and b/Linux-0.95/INSTALL/pfdisk/PFDISK.EXE differ diff --git a/Linux-0.95/INSTALL/pfdisk/PFDISKAZ.C b/Linux-0.95/INSTALL/pfdisk/PFDISKAZ.C new file mode 100644 index 00000000..72c47f6d --- /dev/null +++ b/Linux-0.95/INSTALL/pfdisk/PFDISKAZ.C @@ -0,0 +1,605 @@ +/* + * pfdisk - Partition a Fixed DISK + * by Gordon W. Ross, Jan. 1990 + * + * See the file "pfdisk.doc" for user instructions. + * + * This program uses a simple, line-oriented interpreter, + * designed for both interactive and non-interactive use. + * To facilitate non-interactive use, the output from the + * 'L' (list partitions) command is carefully arranged so it + * can be used directly as command input. Neat trick, eh? + */ + +char *versionString = + "# pfdisk version 1.2.1 by Gordon W. Ross Aug. 1990\nModified by S. Lubkin Oct. 1991\n"; + +/* These don't really matter. The user is asked to set them. */ +#define DEFAULT_CYLS 306 +#define DEFAULT_HEADS 4 +#define DEFAULT_SECTORS 17 +#define PROMPT_STRING "pfdisk> " + +#include +#include +#include +#include "sysdep.h" +#include "syscodes.h" + +typedef unsigned char uchar; +typedef unsigned int uint; +typedef unsigned long ulong; + +struct part { /* An entry in the partition table */ + uchar active; /* active flag (0x80 or 0) */ + uchar b_head; /* begin head */ + uchar b_sec; /* sector */ + uchar b_cyl; /* cylinder */ + uchar sysid; /* system id (see sysid.c) */ + uchar e_head; /* end head */ + uchar e_sec; /* end sector */ + uchar e_cyl; /* end cylinder */ + /* These two are just longs, but this way is machine independent. */ + /* uchar lsBeg[4]; /* logical sectors, beginning Saul */ + ulong lsBeg; /* logical sectors, beginning Saul */ + /* uchar lsLen[4]; /* logical sectors, length Saul */ + ulong lsLen; /* logical sectors, length Saul */ +}; + +#define LOC_PT 0x1BE +#define LOC_NT 0x1AA /* Saul */ +/* #define LOC_NT 0x180 Saul */ +/* #define LOC_GWR 0x1A0 Saul */ +#define LOC_GWR 0x1A9 /* Saul */ +#define MAGIC_LOC 0x1FE +#define MAGIC_0 0x55 +#define MAGIC_1 0xAA +#define MAX_LINE 80 +#define NT_ENTRY_SIZE 5 /* Saul */ +/* Note: Entry in "printf" command, should be manually changed, to +"%-NT_ENTRY_SIZE.NT_ENTRY_SIZEs" Saul */ +/* And header printf line should have blanks adjusted Saul */ + +char s[22]; /* For holding error string */ +char buffer[SECSIZE]; /* The boot block buffer */ +int bufmod=0; /* buffer modified... */ + /* (zero means buffer is unmodified) */ +int useNTable; /* boot sector uses name table */ + +/* device parameters (force someone to set them!) */ +unsigned cyls = DEFAULT_CYLS; +unsigned heads = DEFAULT_HEADS; +unsigned sectors = DEFAULT_SECTORS; + +char *devname; /* device name */ +char cmdline[MAX_LINE]; +char filename[80]; /* used by r/w commands */ +char *prompt; /* null if no tty input */ + +/* Some of these strings are used in more than one place. + * For consistency, I put a newline on all of them. + */ +char h_h[] = "? : Help summary\n"; +char h_l[] = "L : List partition table\n"; +char h_1[] = "1 id first last [name]: set partition 1\n"; +char h_2[] = "2,3,4 ... (like 1) : set respective partition\n"; +char h_a[] = "A n [m, ...] : Activate partition(s) n [m, ...]\n"; +char h_g[] = "G cyls heads sectors : set disk Geometry\n"; +char h_i[] = "I : list known ID numbers\n"; +char h_r[] = "R [optional-file] : Read device (or specified file)\n"; +char h_w[] = "W [optional-file] : Write device (or specified file)\n"; +char h_q[] = "Q[!] : Quit (! means force)\n"; + +char * helpTable[] = { +h_h, h_l, h_1, h_2, h_a, h_g, h_i, h_r, h_w, h_q, +"# (All command letters have lower-case equivalents.)\n", +(char *) 0 }; /* This MUST have a zero as the last element */ + +char *BadArg="Error: bad argument: %s\n"; +char *WarnNotSaved = + "Warning, modified partition table not saved.\n"; + +help() +{ + char ** p; + for (p = helpTable; *p; p++) + printf(*p); +} + +/* forward declarations */ +void checkValidity(); +char * setPartition(); +char * makeActive(); +char * setGeometry(); +ulong chs2long(); +char * nameID(); +int printIDs(); + +main(argc,argv) +int argc; +char *argv[]; +{ + char *cmdp; /* points to command word */ + char *argp; /* points to command args */ + + /* check command line args (device name) */ + if (argc != 2) { + usage(argv[0]); /* See s-sysname.c */ + exit(1); + } + devname = argv[1]; + + /* Should we prompt? */ + prompt = (isatty(fileno(stdin))) ? PROMPT_STRING : (char *) 0; + + /* Print version name. */ + fputs(versionString, stderr); + + /* get disk parameters */ + getGeometry(devname,&cyls,&heads,§ors); + + /* Get the boot block. */ + if (getBBlk(devname, buffer) < 0) + fprintf(stderr,"%s: read failed\n", devname); + checkValidity(); + + if (prompt) fprintf(stderr,"For help, enter: '?'\n"); + + + /* Read and process commands a line at a time. */ + while (1) { + if (prompt) fputs(prompt,stdout); + if (! fgets(cmdline, MAX_LINE, stdin)) break; + + /* Find beginning of command word */ + cmdp = cmdline; + while (isspace(*cmdp)) cmdp++; + + /* find beginning of args */ + argp = cmdp; + while (*argp && !isspace(*argp)) argp++; + while (isspace(*argp) || *argp=='=') argp++; + + switch (*cmdp) { + + case '\0': /* blank line */ + case '#': /* line comment */ + break; + + case '?': case 'h': case 'H': + help(); + break; + + case '1': /* set partition entry */ + case '2': case '3': case '4': + argp = setPartition(cmdp, argp); + if (argp) { /* arg list error */ + fprintf(stderr,BadArg,argp); + fprintf(stderr,h_1); + fprintf(stderr,h_2); + break; + } + bufmod = 1; + break; + + case 'a': case 'A': /* activate partition */ + argp = makeActive(argp); + if (argp) { + fprintf(stderr,BadArg,argp); + fprintf(stderr,h_a); + break; + } + bufmod = 1; + break; + + case 'g': case 'G': /* set disk parameters (Geometry) */ + argp = setGeometry(argp); + if (argp) { /* arg list error */ + fprintf(stderr,BadArg,argp); + fprintf(stderr,h_g); + } + break; + + case 'i': case 'I': /* List known ID numbers */ + printIDs(); + break; + + case 'l': case 'L': /* List the partition table */ + listPTable(); + break; + + case 'q': case 'Q': /* Quit */ + if (bufmod && (cmdp[1] != '!')) { + fprintf(stderr,"\007%s%s\n", WarnNotSaved, + "Use 'wq' or 'q!' (enter ? for help)."); + break; + } + exit(0); + /*NOTREACHED*/ + + case 'r': case 'R': /* read from device or file */ + if (sscanf(argp,"%80s",filename) == 1) { + /* Arg specified, read from filename */ + if (getFile(filename, buffer, SECSIZE) < 0) + fprintf(stderr,"%s: read failed\n", filename); + bufmod = 1; + } else { + /* No arg, use device. */ + if (getBBlk(devname, buffer) < 0) + fprintf(stderr,"%s: read failed\n", devname); + bufmod = 0; + } + checkValidity(); + break; + + case 'w': case 'W': /* Write to file or device */ + if (sscanf(argp,"%80s",filename) == 1) { + /* Arg specified, write to filename */ + if (putFile(filename, buffer, SECSIZE) < 0) + fprintf(stderr, "%s: write failed\n", filename); + } else { /* No arg, use device. */ + if (putBBlk(devname, buffer) < 0) + fprintf(stderr, "%s: write failed\n", devname); + bufmod = 0; + } + if (cmdp[1] == 'q' || cmdp[1] == 'Q') exit(0); + break; + + default: + fprintf(stderr,"'%c': unrecognized. Enter '?' for help.\n", *cmdp); + break; + + } /* switch */ + } /* while */ + if (bufmod) fprintf(stderr, WarnNotSaved); + exit(0); +} /* main */ + + +/* Check for valid boot block (magic number in last two bytes). + * Also, check for presence of partition name table. + */ +void checkValidity() +{ + /* Check the magic number. */ + if ((buffer[MAGIC_LOC] & 0xFF) != MAGIC_0 || + (buffer[MAGIC_LOC+1] & 0xFF) != MAGIC_1 ) { + /* The boot sector is not valid -- Fix it. */ + buffer[MAGIC_LOC] = MAGIC_0; + buffer[MAGIC_LOC+1] = MAGIC_1; + bufmod = 1; + fprintf(stderr, +"\n\tWarning: The boot sector has an invalid magic number.\n\ +\tThe magic number has been fixed, but the other contents\n\ +\tare probably garbage. Initialize using the command:\n\ +\t\tR boot-program-file (i.e. bootmenu.bin)\n\ +\tthen set each partition entry if necessary.\n"); + } + + /* Does it use a name table (for a boot menu)? + * My boot program does, and can be identified by + * finding my name in a particular (unused) area. + */ + useNTable = ( buffer[LOC_GWR] == (char)0x3A ); /* Saul */ + /* useNTable = !strcmp(&buffer[LOC_GWR], "Gordon W. Ross"); Saul */ + +} + +char * setPartition(cmdp,argp) /* return string on error */ +char *cmdp,*argp; +{ + struct part *pp; /* partition entry */ + char * np; /* name table pointer */ + char tmpname[20]; + char * newname = tmpname; /* name field */ + int index; /* partition index (0..3) */ + uint id; /* ID code (see syscodes.c) */ + uint first,last; /* user supplied cylinders */ + uint c,h,s; /* working cyl,head,sect, */ + int i; /* returned by sscanf */ + ulong lsbeg, lslen; /* logical begin, length */ + + /* Value check the index */ + index = *cmdp - '1'; + if (index < 0 || index > 3) + return("index"); + pp = (struct part *) &buffer[LOC_PT + index * 16]; + np = &buffer[LOC_NT + index * NT_ENTRY_SIZE]; /* Saul */ + /* np = &buffer[LOC_NT + index * 8]; Saul */ + + /* Read System ID */ + if ((i=sscanf(argp,"%d%d%d%s", &id, &first, &last, newname)) < 1) + return("id"); + + /* If ID==0, just clear out the entry and return. */ + if (id == 0) { + strncpy( (char *) pp, "", 16); + if (useNTable) strncpy( np, "", NT_ENTRY_SIZE); /* Saul */ + /* if (useNTable) strncpy( np, "", 8); Saul */ + return((char *)0); + } + + /* Read first and last cylinder */ + if (i < 3) + return("first last (missing)"); + + /* Reasonable start,end cylinder numbers? */ + if (first > last) return("first > last"); + if (first > 1023) return("first > 1023"); + if (last >= cyls) return("last >= cyls"); + + /* Get (optional) system name. */ + if (i == 3) { /* no name given, use default */ + newname = nameID(id); + } + else useNTable = 1; + + /* Set the ID and name. */ + pp->sysid = id; + if (useNTable) { + strncpy(np, newname, NT_ENTRY_SIZE); /* Saul */ + /* strncpy(np, newname, 8); Saul */ + /* strcpy(&buffer[LOC_GWR], "Gordon W. Ross"); Saul */ + buffer[LOC_GWR] = (char)0x3A; /* Saul */ + } + + /* set beginning c,h,s */ + c = first; + /* if c == 0, head == 1 (reserve track 0) */ + h = (first) ? 0 : 1; + s = 1; + pp->b_cyl = c & 0xFF; + pp->b_head = h; + pp->b_sec = s | ((c >> 2) & 0xC0); + /* Set the logical sector begin field */ + lsbeg = lslen = chs2long(c,h,s); /* using lslen as temp. */ + /* pp->lsBeg[0] = lslen & 0xff; lslen >>= 8; + pp->lsBeg[1] = lslen & 0xff; lslen >>= 8; + pp->lsBeg[2] = lslen & 0xff; lslen >>= 8; + pp->lsBeg[3] = lslen & 0xff; lslen >>= 8; Saul */ + pp->lsBeg = lslen; /* Saul */ + + /* set ending c,h,s (last may be larger than 1023) */ + c = (last>1023) ? 1023 : last; /* limit c to 1023 */ + h = heads - 1; s = sectors; + pp->e_cyl = c & 0xFF; + pp->e_head = h; + pp->e_sec = s | ((c >> 2) & 0xC0); + /* Set the logical sector length field (using REAL end cylinder) */ + lslen = chs2long(last,h,s) + 1 - lsbeg; + /* pp->lsLen[0] = lslen & 0xff; lslen >>= 8; + pp->lsLen[1] = lslen & 0xff; lslen >>= 8; + pp->lsLen[2] = lslen & 0xff; lslen >>= 8; + pp->lsLen[3] = lslen & 0xff; lslen >>= 8; Saul */ + pp->lsLen = lslen; /* Saul */ + + return((char *)0); /* success */ +} /* setPartition() */ + +char * makeActive(argp) /* return error string or zero */ +char *argp; +{ + struct part *pp; /* partition entry */ + int i,act1,act2,act3,act4,act5; /* which one becomes active */ + + act1=0; + act2=0; + act3=0; + act4=0; + if ((i=sscanf(argp,"%d%d%d%d%d", &act1, &act2, &act3, &act4, &act5)) < 1) + return("missing partition number"); + if ( i > 4) + return("at most four partition numbers"); + act1--; /* make it zero-origin */ + act2--; /* make it zero-origin */ + act3--; /* make it zero-origin */ + act4--; /* make it zero-origin */ + + i=0; pp = (struct part *) &buffer[LOC_PT]; + while (i<4) { + if (pp->sysid == 0 && (i == act1|| i == act2 || i == act3 || i == act4)) { + sprintf(s, "partition %d empty", i+1); + return(s); + } + i++; pp++; + } + i=0; pp -= 4; + while (i<4) { + if (i == act1|| i == act2 || i == act3 || i == act4) + pp->active = 0x80; + else + pp->active = 0; + i++; pp++; + } + return((char *)0); +} + +char * setGeometry(argp) /* return string on error */ +char *argp; +{ + int c,h,s; + + if (sscanf(argp,"%d%d%d", &c, &h, &s) < 3) + return("(missing)"); + if (c<1) return("cyls"); + if (h<1) return("heads"); + if (s<1) return("sectors"); + cyls=c; heads=h; sectors=s; + return((char *)0); +} + +listPTable() /* print out partition table */ +{ + struct part * pp; /* partition table entry */ + char *name; + int i; /* partition number */ + /* int numActive=0; /* active partition [1-4], 0==none */ + char Active[20]; /* active partitions [1-4], 0==none */ + uint pbc,pbh,pbs; /* physical beginning c,h,s */ + uint pec,peh,pes; /* physical ending c,h,s */ + uint lbc,lbh,lbs; /* logical beginning c,h,s */ + uint lec,leh,les; /* logical ending c,h,s */ + ulong lsbeg,lslen; /* logical sectors: begin, length */ + + strcpy(Active, "active:"); + printf("# Partition table on device: %s\n", devname); + printf("geometry %d %d %d (cyls heads sectors)\n", + cyls, heads, sectors); + /* printf("# ID First(cyl) Last(cyl) Name "); Saul */ + printf("# ID First(cyl) Last(cyl) Name "); /* Saul */ + printf("# start, length (sectors)\n"); + + for (i=0; i<4; i++) { + pp = (struct part *) &buffer[LOC_PT + i * 16]; + + if (pp->active) { + char s[3]; + sprintf(s, " %d", i+1); + strcat(Active,s); + if (pp->active != 0x80) + fprintf(stderr, "Warning: Partition %d is active, with the illegal activity byte %d.\nCorrect with the \"A\" command.\n", i+1, pp->active); + /* if(numActive) + fprintf(stderr,"Error: multiple active partitions.\n"); + else numActive = i+1; */ + } + + /* physical beginning c,h,s */ + pbc = pp->b_cyl & 0xff | (pp->b_sec << 2) & 0x300; + pbh = pp->b_head; + pbs = pp->b_sec & 0x3F; + + /* physical ending c,h,s */ + pec = pp->e_cyl & 0xff | (pp->e_sec << 2) & 0x300; + peh = pp->e_head; + pes = pp->e_sec & 0x3F; + + /* compute logical beginning (c,h,s) */ + /* lsbeg = ((((((pp->lsBeg[3] ) << 8 ) + | pp->lsBeg[2] ) << 8 ) + | pp->lsBeg[1] ) << 8 ) + | pp->lsBeg[0] ; Saul */ + lsbeg = pp->lsBeg; /* Saul */ + long2chs(lsbeg, &lbc, &lbh, &lbs); + /* compute logical ending (c,h,s) */ + /* lslen = ((((((pp->lsLen[3]) << 8 ) + | pp->lsLen[2]) << 8 ) + | pp->lsLen[1]) << 8 ) + | pp->lsLen[0] ; Saul */ + lslen = pp->lsLen; /* Saul*/ + /* keep beginning <= end ... */ + if (lslen > 0) long2chs(lsbeg+lslen-1, &lec, &leh, &les); + else long2chs(lsbeg, &lec, &leh, &les); + + if (useNTable) + name = &buffer[LOC_NT + i * NT_ENTRY_SIZE ]; /* Saul */ + /* name = &buffer[LOC_NT + i * 8]; Saul */ + else + name = nameID((uint) pp->sysid); + + /* show physical begin, logical end (works for cyl>1023) */ + /* # ID First(cyl) Last(cyl) Name... # ... */ + /* printf("%d %3d %4d %4d %-8.8s # %ld, %ld\n", Saul */ + printf("%d %3d %4d %4d %-5.5s # %ld, %ld\n", /* Saul */ + i+1, pp->sysid, pbc, lec, name, lsbeg, lslen ); + + /* That's all, for an empty partition. */ + if (pp->sysid == 0) continue; + + /* + * Now do some consistency checks... + */ + + /* Same physical / logical beginning? */ + if (pbc != lbc || pbh != lbh || pbs != lbs ) { + printf("# note: first(%d): ", i+1); + printf("phys=(%d,%d,%d) ", pbc, pbh, pbs); + printf("logical=(%d,%d,%d)\n",lbc, lbh, lbs); + } + /* Same physical / logical ending? */ + if (pec != lec || peh != leh || pes != les ) { + printf("# note: last(%d): ", i+1); + printf("phys=(%d,%d,%d) ", pec, peh, pes); + printf("logical=(%d,%d,%d)\n",lec, leh, les); + } + + /* Beginning on cylinder boundary? */ + if (pbc == 0) { /* exception: start on head 1 */ + if (pbh != 1 || pbs != 1) { + printf("# note: first(%i): ", i+1); + printf("phys=(%d,%d,%d) ", pbc, pbh, pbs); + printf("should be (%d,1,1)\n", pbc); + } + } else { /* not on cyl 0 */ + if (pbh != 0 || pbs != 1) { + printf("# note: first(%i): ", i+1); + printf("phys=(%d,%d,%d) ", pbc, pbh, pbs); + printf("should be (%d,0,1)\n", pbc); + } + } + + /* Ending on cylinder boundary? */ + if (peh != (heads-1) || pes != sectors) { + printf("# note: last(%i): ", i+1); + printf("phys=(%d,%d,%d) ", pec, peh, pes); + printf("should be (%d,%d,%d)\n", + pec, heads-1, sectors); + } + + } /* for */ + if ( !Active[7] ) /* No active partitions */ + strcat(Active, " 0 (none)"); + strcat(Active, "\n"); + printf(Active); +/* printf("active: %d %s\n", numActive, + (numActive) ? "" : "(none)"); */ +} /* listPTable() */ + +ulong chs2long(c,h,s) +uint c,h,s; +{ + ulong l; + if (s<1) s=1; + l = c; l *= heads; + l += h; l *= sectors; + l += (s - 1); + return(l); +} + +long2chs(ls, c, h, s) /* convert logical sec-num to c,h,s */ +ulong ls; /* Logical Sector number */ +uint *c,*h,*s; /* cyl, head, sector */ +{ + int spc = heads * sectors; + *c = ls / spc; + ls = ls % spc; + *h = ls / sectors; + *s = ls % sectors + 1; /* sectors count from 1 */ +} + +char * nameID(n) +unsigned int n; +{ + struct intString *is; + + is = sysCodes; + while (is->i) { + if (is->i == n) return(is->s); + is++; + } + if (!n) return(is->s); + return("unknown"); +} + +int printIDs() /* print the known system IDs */ +{ + struct intString * is = sysCodes; + + /* This might need to do more processing eventually, i.e. + * if (prompt) { ... do more processing ... } + */ + printf("_ID_\t__Name__ ____Description____\n"); + while (is->i) { + printf("%3d\t%s\n", is->i, is->s); + is++; + } +} diff --git a/Linux-0.95/INSTALL/pfdisk/SYSCODES.C b/Linux-0.95/INSTALL/pfdisk/SYSCODES.C new file mode 100644 index 00000000..11f5c77e --- /dev/null +++ b/Linux-0.95/INSTALL/pfdisk/SYSCODES.C @@ -0,0 +1,43 @@ +/* This file holds all knowledge of partition ID codes. + * Thanks to leendert@cs.vu.nl (Leendert van Doorn) for + * collecting most of this information. + */ + +#define extern +#include "syscodes.h" +#undef extern + +/* Note that my boot program menu can only use the first 8 characters + * of these names. The colon in the nineth position shows where the + * first truncated char is. (There's not much room in the bootblock!) + * changed sysCodes[] below, adding SIZE tms */ +struct intString sysCodes[SIZE] = { +{ 0x01, "DOS12 :12-bit FAT" }, +{ 0x02, "XENIX :root" }, +{ 0x03, "XENIX :usr" }, +{ 0x04, "DOS16 :16-bit FAT" }, +{ 0x05, "DOSex :DOS 3.3 extended volume" }, +{ 0x06, "DOSbi :DOS 4.0 large volume" }, +{ 0x07, "OS/2 :OS/2 (or QNX or Adv. UNIX...)" }, +{ 0x08, "AIX :file system" }, +{ 0x09, "AIXbt:boot partition" }, + +{ 0x10, "OPUS :?" }, +{ 0x40, "VENIX :Venix 80286" }, +{ 0x51, "NOVEL :?" }, +{ 0x52, "CPM :?" }, +{ 0x63, "UNIX :System V/386" }, +{ 0x64, "NOVEL :?" }, +{ 0x75, "PC/IX :?" }, +{ 0x80, "Minix :Minix (ver. 1.4a and earlier)" }, +{ 0x81, "Minix :Minix (ver. 1.4b and later)" }, +{ 0x93, "Ameba :Amoeba file system" }, +{ 0x94, "Ameba :Amoeba bad block table?" }, +{ 0xDB, "C.DOS :Concurrent DOS" }, + +/* { 0xF2, "DOS-2nd :DOS 3.3+ second partition" }, */ +/* { 0xFF, "BAD-TRK :Bad track table?" }, */ + +/* Make sure this is last! */ +{ 0, "empty" } +}; diff --git a/Linux-0.95/INSTALL/pfdisk/SYSCODES.H b/Linux-0.95/INSTALL/pfdisk/SYSCODES.H new file mode 100644 index 00000000..6fd314da --- /dev/null +++ b/Linux-0.95/INSTALL/pfdisk/SYSCODES.H @@ -0,0 +1,4 @@ +#define SIZE 40 /* added tms */ +struct intString { unsigned int i; char * s; }; +extern struct intString sysCodes[SIZE]; /* was sysCodes[] modified tms */ + diff --git a/Linux-0.95/INSTALL/pfdisk/SYSDEP.H b/Linux-0.95/INSTALL/pfdisk/SYSDEP.H new file mode 100644 index 00000000..1d26b47d --- /dev/null +++ b/Linux-0.95/INSTALL/pfdisk/SYSDEP.H @@ -0,0 +1,22 @@ +/* communicate declarations from the files: s_*.c */ + +#define SECSIZE 0x200 + +extern int usage(); /* print a usage message */ + /* (char *progname) */ + +extern void getGeometry(); /* determine disk parameters */ + /* (char *dev, uint *cyls, uint *heads, uint *sectors) */ + +extern int getFile(); /* open, read, close, return(num-read) */ + /* (char *name, char *buf, int len) */ + +extern int putFile(); /* open, write, close, return(num-writen) */ + /* (char *name, char *buf, int len) */ + +extern int getBBlk(); /* open, read, close, return(num-read) */ + /* (char *dev, char *buf) */ + +extern int putBBlk(); /* open, write, close, return(num-writen) */ + /* (char *dev, char *buf) */ + diff --git a/Linux-0.95/INSTALL/pfdisk/S_MSDOS.C b/Linux-0.95/INSTALL/pfdisk/S_MSDOS.C new file mode 100644 index 00000000..ddeab974 --- /dev/null +++ b/Linux-0.95/INSTALL/pfdisk/S_MSDOS.C @@ -0,0 +1,163 @@ +/* This file contains system-specific functions for MS-DOS. + * The program pfdisk.c calls these routines. + */ +#include +#include +#include +#include +#include + +#define extern +#include "sysdep.h" +#undef extern + +int usage(prog) /* print a usage message */ +char *prog; /* program name */ +{ + fprintf(stderr,"Usage: %s \n", prog); + fprintf(stderr,"\twhere is a digit [0-9]\n"); +} + +void getGeometry(name, c, h, s) +char *name; /* device name */ +unsigned *c,*h,*s; /* cyls, heads, sectors */ +{ + int dev; /* hard disk number */ + union REGS regs; + struct SREGS sregs; + + if (name[0] < '0' || + name[0] > '9' || + name[1] != 0 ) + { + fprintf(stderr,"%s: device name must be a digit\n", name); + return; + } + dev = (name[0] - '0'); + + regs.h.ah = 8; /* get param. */ + regs.h.dl = dev | 0x80; + + int86x(0x13,®s,®s,&sregs); + + /* Are that many drives responding? */ + if (regs.h.dl <= dev ) { + fprintf(stderr,"%s: drive not found\n", name); + return; + } + if (regs.x.cflag) { + fprintf(stderr,"%s: can't get disk parameters\n", name); + return; + } + *c = ((((int) regs.h.cl << 2) & 0x300) | regs.h.ch) + 1; + *h = regs.h.dh + 1; + *s = regs.h.cl & 0x3F; +} + +int getFile(name, buf, len) /* read file into buffer */ +char *name, *buf; +int len; +{ /* (open, read, close) */ + int devfd, retval; + + devfd = open(name, O_RDONLY|O_BINARY, 0); + if (devfd < 0) { + fprintf(stderr,"%s: can't open for reading\n", name); + return(devfd); + } + retval = read(devfd, buf, len); + if (retval < 0) + fprintf(stderr,"%s: read failed\n", name); + close(devfd); + return(retval); +} + +int putFile(name, buf, len) /* write buffer to file */ +char *name, *buf; +int len; +{ /* (open, write, close) */ + int devfd, retval; + + devfd = open(name, + O_WRONLY|O_CREAT|O_BINARY, + S_IREAD|S_IWRITE ); /* stupid DOS... */ + if (devfd < 0) { + fprintf(stderr,"%s: can't open for writing\n", name); + return(devfd); + } + retval = write(devfd, buf, len); + if (retval < 0) + fprintf(stderr,"%s: write failed\n", name); + close(devfd); + return(retval); +} + +int getBBlk(name, buf) /* read boot block into buffer */ +char *name, *buf; +{ /* BIOS absolute disk read */ + int dev; + union REGS regs; + struct SREGS sregs; + + if (name[0] < '0' || + name[0] > '9' || + name[1] != 0 ) + { + fprintf(stderr,"%s: device name must be a digit\n",name); + return(-1); + } + dev = (name[0] - '0'); + + segread(&sregs); /* get ds */ + sregs.es = sregs.ds; /* buffer address */ + regs.x.bx = (int) buf; + + regs.h.ah = 2; /* read */ + regs.h.al = 1; /* sector count */ + regs.h.ch = 0; /* track */ + regs.h.cl = 1; /* start sector */ + regs.h.dh = 0; /* head */ + regs.h.dl = dev|0x80; /* drive */ + + int86x(0x13,®s,®s,&sregs); + if (regs.x.cflag) { + fprintf(stderr,"%s: read failed\n", name); + return(-1); + } + return(SECSIZE); +} + +int putBBlk(name, buf) /* write buffer to boot block */ +char *name, *buf; +{ /* BIOS absolute disk write */ + int dev; + union REGS regs; + struct SREGS sregs; + + if (name[0] < '0' || + name[0] > '9' || + name[1] != 0 ) + { + fprintf(stderr,"%s: device name must be a digit\n", name); + return(-1); + } + dev = (name[0] - '0'); + + segread(&sregs); /* get ds */ + sregs.es = sregs.ds; /* buffer address */ + regs.x.bx = (int) buf; + + regs.h.ah = 3; /* write */ + regs.h.al = 1; /* sector count */ + regs.h.ch = 0; /* track */ + regs.h.cl = 1; /* start sector */ + regs.h.dh = 0; /* head */ + regs.h.dl = dev|0x80; /* drive */ + + int86x(0x13,®s,®s,&sregs); + if (regs.x.cflag) { + fprintf(stderr,"%s: write failed\n",name); + return(-1); + } + return(SECSIZE); +} diff --git a/Linux-0.95/INSTALL/pfdisktc.zip b/Linux-0.95/INSTALL/pfdisktc.zip new file mode 100644 index 00000000..92dddc3e Binary files /dev/null and b/Linux-0.95/INSTALL/pfdisktc.zip differ diff --git a/Linux-0.95/INSTALL/rawrite.c b/Linux-0.95/INSTALL/rawrite.c new file mode 100644 index 00000000..3772b2f7 --- /dev/null +++ b/Linux-0.95/INSTALL/rawrite.c @@ -0,0 +1,182 @@ +/* + rawrite.c Write a binary image to a 360K diskette. + By Mark Becker + + Usage: + MS-DOS prompt> RAWRITE + + And follow the prompts. + +History +------- + + 1.0 - Initial release + 1.1 - Beta test (fixing bugs) 4/5/91 + Some BIOS's don't like full-track writes. + 1.101 - Last beta release. 4/8/91 + Fixed BIOS full-track write by only + writing 3 sectors at a time. + 1.2 - Final code and documentation clean-ups. 4/9/91 +*/ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define FALSE 0 +#define TRUE (!FALSE) + +#define SECTORSIZE 512 + +#define RESET 0 +#define LAST 1 +#define READ 2 +#define WRITE 3 +#define VERIFY 4 +#define FORMAT 5 + +int done; + +/* + Catch ^C and ^Break. +*/ +int handler(void) +{ + done = TRUE; + return(0); +} +void msg(char (*s)) +{ + fprintf(stderr, "%s\n", s); + _exit(1); +} +/* + Identify the error code with a real error message. +*/ +void Error(int (status)) +{ + switch (status) { + case 0x00: msg("Operation Successful"); break; + case 0x01: msg("Bad command"); break; + case 0x02: msg("Address mark not found"); break; + case 0x03: msg("Attempt to write on write-protected disk"); break; + case 0x04: msg("Sector not found"); break; + case 0x05: msg("Reset failed (hard disk)"); break; + case 0x06: msg("Disk changed since last operation"); break; + case 0x07: msg("Drive parameter activity failed"); break; + case 0x08: msg("DMA overrun"); break; + case 0x09: msg("Attempt to DMA across 64K boundary"); break; + case 0x0A: msg("Bad sector detected"); break; + case 0x0B: msg("Bad track detected"); break; + case 0x0C: msg("Unsupported track"); break; + case 0x10: msg("Bad CRC/ECC on disk read"); break; + case 0x11: msg("CRC/ECC corrected data error"); break; + case 0x20: msg("Controller has failed"); break; + case 0x40: msg("Seek operation failed"); break; + case 0x80: msg("Attachment failed to respond"); break; + case 0xAA: msg("Drive not ready (hard disk only"); break; + case 0xBB: msg("Undefined error occurred (hard disk only)"); break; + case 0xCC: msg("Write fault occurred"); break; + case 0xE0: msg("Status error"); break; + case 0xFF: msg("Sense operation failed"); break; + } + _exit(1); +} + +/* + Identify what kind of diskette is installed in the specified drive. + Return the number of sectors per track assumed as follows: + 9 - 360 K and 720 K 5.25". +15 - 1.2 M HD 5.25". +18 - 1.44 M 3.5". +*/ +int nsects(int (drive)) +{ + static int nsect[] = {18, 15, 9}; + + char *buffer; + int i, status; +/* + Read sector 1, head 0, track 0 to get the BIOS running. +*/ + buffer = (char *)malloc(SECTORSIZE); + biosdisk(RESET, drive, 0, 0, 0, 0, buffer); + status = biosdisk(READ, drive, 0, 10, 1, 1, buffer); + if (status == 0x06) /* Door signal change? */ + status = biosdisk(READ, drive, 0, 0, 1, 1, buffer); + + for (i=0; i < sizeof(nsect)/sizeof(int); ++i) { + biosdisk(RESET, drive, 0, 0, 0, 0, buffer); + status = biosdisk(READ, drive, 0, 0, nsect[i], 1, buffer); + if (status == 0x06) + status = biosdisk(READ, drive, 0, 0, nsect[i], 1, buffer); + if (status == 0x00) break; + } + if (i == sizeof(nsect)/sizeof(int)) { + msg("Can't figure out how many sectors/track for this diskette."); + } + free(buffer); + return(nsect[i]); +} + +void main(void) +{ + char fname[MAXPATH]; + char *buffer, *pbuf; + int count, fdin, drive, head, track, status, spt, buflength, ns; + + puts("RaWrite 1.2 - Write disk file to raw floppy diskette\n"); + ctrlbrk(handler); + printf("Enter source file name: "); + scanf("%s", fname); + _fmode = O_BINARY; + if ((fdin = open(fname, O_RDONLY)) <= 0) { + perror(fname); + exit(1); + } + + printf("Enter destination drive: "); + scanf("%s", fname); + drive = fname[0]; + drive = (islower(drive) ? toupper(drive) : drive) - 'A'; + printf("Please insert a formatted diskette into "); + printf("drive %c: and press -ENTER- :", drive + 'A'); + while (bioskey(1) == 0) ; /* Wait... */ + if ((bioskey(0) & 0x7F) == 3) exit(1); /* Check for ^C */ + putchar('\n'); + done = FALSE; +/* + * Determine number of sectors per track and allocate buffers. + */ + spt = nsects(drive); + buflength = spt * SECTORSIZE; + buffer = (char *)malloc(buflength); + printf("Number of sectors per track for this disk is %d\n", spt); + printf("Writing image to drive %c:. Press ^C to abort.\n", drive+'A'); +/* + * Start writing data to diskette until there is no more data to write. + */ + head = track = 0; + while ((count = read(fdin, buffer, buflength)) > 0 && !done) { + pbuf = buffer; + for (ns = 1; count > 0 && !done; ns+=3) { + printf("Track: %02d Head: %2d Sector: %2d\r", track, head, ns); + status = biosdisk(WRITE, drive, head, track, ns, 3, pbuf); + + if (status != 0) Error(status); + + count -= (3*SECTORSIZE); + pbuf += (3*SECTORSIZE); + } + if ((head = (head + 1) & 1) == 0) ++track; + } + if (eof(fdin)) { + printf("\nDone.\n"); + biosdisk(2, drive, 0, 0, 1, 1, buffer); /* Retract head */ + } +} /* end main */ diff --git a/Linux-0.95/INSTALL/rawrite.doc b/Linux-0.95/INSTALL/rawrite.doc new file mode 100644 index 00000000..f4871d1f --- /dev/null +++ b/Linux-0.95/INSTALL/rawrite.doc @@ -0,0 +1,86 @@ +RaWrite 1.2 +----------- + +Purpose +------- + +Write a disk image file to a 360K floppy disk. + + +Equipment/Software Requirements +------------------------------- + +PC/XT/AT with a floppy disk drive capable of reading and writing a 360K +diskette. + +This program uses generic low-level BIOS diskette read/write functions. It +should be portable to nearly every PC in existance. PS/2's should be able +to run RawWrite but this has not been tested. + + +CAVEAT +------ + +This program will write ANY disk file to a floppy, overwriting any previous +information that may have been present. If you wish to re-use a diskette +under MS-DOS thats been written to by RawWrite then the disk will need to be +reformatted; all MS-DOS specific information will have been erased. + + +How to Compile +-------------- + +TCC rawrite.c + +The source code is specific to Borland International's Turbo C 2.01 and has +been tested in all memory models. + + +Usage +----- + +C> RAWRITE + +And follow the prompts. All arguments are case-insensitive. + +A sample run is shown below. The disk file being written, in this example, +is named DEMODISK and the destination - where the image is being written - +is the B: drive. + +This program may be aborted at any time by typing ^C. + + +Sample Run +---------- + +C> RAWRITE +RaWrite 1.2 - Write disk file to raw floppy diskette + +Enter source file name: DEMODISK +Enter destination drive: B +Please insert a formatted 360K diskette into drive B: and press -ENTER- : +Writing image to drive B: + + +Errors +------ + +RaWrite attempts to determine if the diskette is a 360K, 720K, 1.2M, or +1.44M diskette by reading specific sectors. If the inserted diskette is not +one of the mentioned types, then RaWrite will abort with a short error +message. + +Errors such as write protect, door open, bad disk, bad sector, etc. cause a +program abort with a short error message. + + +History +------- + + 1.0 - Initial release + 1.1 - Beta test (fixing bugs) 4/5/91 + Some BIOS's don't like full-track writes. + 1.101 - Last beta release. 4/8/91 + Fixed BIOS full-track write by only only + writing 3 sectors at a time. + 1.2 - Final code and documentation clean-ups. 4/9/91 diff --git a/Linux-0.95/INSTALL/rawrite.exe b/Linux-0.95/INSTALL/rawrite.exe new file mode 100644 index 00000000..a4a464ba Binary files /dev/null and b/Linux-0.95/INSTALL/rawrite.exe differ diff --git a/Linux-0.95/binaries/sbin/kermit5A.tar.Z b/Linux-0.95/binaries/sbin/kermit5A.tar.Z new file mode 100644 index 00000000..1c207378 Binary files /dev/null and b/Linux-0.95/binaries/sbin/kermit5A.tar.Z differ diff --git a/Linux-0.95/binaries/system/boot92.05.18.Z b/Linux-0.95/binaries/system/boot92.05.18.Z new file mode 100644 index 00000000..a634d3a8 Binary files /dev/null and b/Linux-0.95/binaries/system/boot92.05.18.Z differ diff --git a/Linux-0.95/binaries/usr.bin/flex2.3.7.tar.Z b/Linux-0.95/binaries/usr.bin/flex2.3.7.tar.Z new file mode 100644 index 00000000..b6cc1a95 Binary files /dev/null and b/Linux-0.95/binaries/usr.bin/flex2.3.7.tar.Z differ diff --git a/Linux-0.95/binaries/usr.bin/fm.tar.Z b/Linux-0.95/binaries/usr.bin/fm.tar.Z new file mode 100644 index 00000000..7b5f3042 Binary files /dev/null and b/Linux-0.95/binaries/usr.bin/fm.tar.Z differ diff --git a/Linux-0.95/binaries/usr.bin/gmake-3.62.tar.Z b/Linux-0.95/binaries/usr.bin/gmake-3.62.tar.Z new file mode 100644 index 00000000..53404281 Binary files /dev/null and b/Linux-0.95/binaries/usr.bin/gmake-3.62.tar.Z differ diff --git a/Linux-0.95/binaries/usr.bin/gmake-3_62_patch.txt b/Linux-0.95/binaries/usr.bin/gmake-3_62_patch.txt new file mode 100644 index 00000000..0a901a9c --- /dev/null +++ b/Linux-0.95/binaries/usr.bin/gmake-3_62_patch.txt @@ -0,0 +1,312 @@ +From: simonm@dcs.glasgow.ac.uk (Simon Marlow) +Newsgroups: alt.os.linux +Subject: Re: Various Problems.. +Message-ID: <1992Mar24.120332.14976@dcs.glasgow.ac.uk> +Date: 24 Mar 92 12:03:32 GMT +References: +Organization: Glasgow University Computing Science Dept. +Lines: 301 + + +ijw11@phx.cam.ac.uk (Ian Wells) writes: + +>I have problems with make too. Mine reports +>(null): situid: not owner +>or something similar, if I'm not root. I've tried u+s on the binary to no +>effect, so what's the problem? +>Ian. + +Here are the diffs I made when I compiled gmake-3.62 (as far as I know +there are none of the common bugs ascociated with these diffs - eg +setuid problems, Ctrl-C not working etc.) + +Unfortunately I compiled with gcc2 & shared libs so I can't really +upload the binary, although I could upload the .o file ready for +linking. Mail me if this would be useful. + +Simon. + +diff -cr gmake-3.62//Makefile gmake-linux//Makefile +*** gmake-3.62//Makefile Thu Nov 21 15:58:00 1991 +--- gmake-linux//Makefile Mon Mar 23 20:27:39 1992 +*************** +*** 22,30 **** + #CC line is new (WDP) + CC=gcc + # CFLAGS = $(defines) -g +! CFLAGS = $(defines) -O + # LDFLAGS = -g +! LDFLAGS = + + # Define these for your system as follows: + # -DUSG System V +--- 22,30 ---- + #CC line is new (WDP) + CC=gcc + # CFLAGS = $(defines) -g +! CFLAGS = $(defines) -O2 + # LDFLAGS = -g +! LDFLAGS = -s + + # Define these for your system as follows: + # -DUSG System V +*************** +*** 42,48 **** + # without complaint but produce losing code, + # so beware. + # NeXT 1.0a uses an old version of GCC, which required -D__inline=inline. +! defines = + + # Define these for your system as follows: + # -DUMAX Encore UMAX +--- 42,48 ---- + # without complaint but produce losing code, + # so beware. + # NeXT 1.0a uses an old version of GCC, which required -D__inline=inline. +! defines = -DPOSIX -DLINUX -DHAVE_DUP2 + + # Define these for your system as follows: + # -DUMAX Encore UMAX +*************** +*** 56,62 **** + # Define: + # -DNLIST_NAME_UNION If `struct nlist' has a n_un member. + # -DNLIST_NAME_ARRAY If `n_name' is an array. +! LOAD_AVG = + + # If you don't want archive support, comment these out. + ARCHIVES = arscan.o ar.o +--- 56,62 ---- + # Define: + # -DNLIST_NAME_UNION If `struct nlist' has a n_un member. + # -DNLIST_NAME_ARRAY If `n_name' is an array. +! LOAD_AVG = -DNO_LDAV + + # If you don't want archive support, comment these out. + ARCHIVES = arscan.o ar.o +*************** +*** 84,102 **** + # Comment this out if POSIX.2 glob is installed on your system + # (it's in the GNU C Library, so if you're using that, this is + # not needed at all.) +! globdep = glob/libglob.a + + # Library containing POSIX.2 `glob' function. + # Comment this line out if it's in the C library (which is the case if you + # are using the GNU C Library), or change it to the appropriate file name + # or -l switch. +! globlib = $(globdep) + + # Name under which to install GNU make. + instname = make + # WDP: +! prefix = /usr/local/gnu +! ARCH:sh = /bin/arch + + # Directory to install `make' in. + bindir = $(prefix)/bin/$(ARCH) +--- 84,102 ---- + # Comment this out if POSIX.2 glob is installed on your system + # (it's in the GNU C Library, so if you're using that, this is + # not needed at all.) +! #globdep = glob/libglob.a + + # Library containing POSIX.2 `glob' function. + # Comment this line out if it's in the C library (which is the case if you + # are using the GNU C Library), or change it to the appropriate file name + # or -l switch. +! #globlib = $(globdep) + + # Name under which to install GNU make. + instname = make + # WDP: +! prefix = /usr/local +! #ARCH:sh = /bin/arch + + # Directory to install `make' in. + bindir = $(prefix)/bin/$(ARCH) +diff -cr gmake-3.62//commands.c gmake-linux//commands.c +*** gmake-3.62//commands.c Tue Oct 8 20:20:30 1991 +--- gmake-linux//commands.c Mon Mar 23 20:22:12 1992 +*************** +*** 342,348 **** + int sig; + { + signal (sig, SIG_DFL); +! #ifndef USG + (void) sigsetmask (0); + #endif + +--- 342,348 ---- + int sig; + { + signal (sig, SIG_DFL); +! #if !defined(USG) && !defined(LINUX) + (void) sigsetmask (0); + #endif + +diff -cr gmake-3.62//job.c gmake-linux//job.c +*** gmake-3.62//job.c Thu Oct 24 21:58:34 1991 +--- gmake-linux//job.c Mon Mar 23 20:10:34 1992 +*************** +*** 117,122 **** +--- 117,123 ---- + extern int setgid (), getgid (); + #endif /* GNU C library. */ + ++ #ifndef LINUX + #ifndef USG + extern int getdtablesize (); + #else +*************** +*** 123,128 **** +--- 124,130 ---- + #include + #define getdtablesize() NOFILE + #endif ++ #endif + + extern void wait_to_start_job (); + extern int start_remote_job_p (); +*************** +*** 180,186 **** + + extern int fatal_signal_mask; + +! #ifdef USG + /* Set nonzero in the interval when it's possible that we may see a dead + child that's not in the `children' chain. */ + static int unknown_children_possible = 0; +--- 182,188 ---- + + extern int fatal_signal_mask; + +! #if defined(USG) || defined(LINUX) + /* Set nonzero in the interval when it's possible that we may see a dead + child that's not in the `children' chain. */ + static int unknown_children_possible = 0; +*************** +*** 192,198 **** + static void + block_signals () + { +! #ifdef USG + + /* Tell child_handler that it might see children that aren't yet + in the `children' chain. */ +--- 194,200 ---- + static void + block_signals () + { +! #if defined(USG) || defined(LINUX) + + /* Tell child_handler that it might see children that aren't yet + in the `children' chain. */ +*************** +*** 216,222 **** + static void + unblock_signals () + { +! #ifdef USG + + (void) SIGNAL (SIGCLD, child_handler); + +--- 218,224 ---- + static void + unblock_signals () + { +! #if defined(USG) || defined(LINUX) + + (void) SIGNAL (SIGCLD, child_handler); + +*************** +*** 396,402 **** + if (c == 0) + { + /* An unknown child died. */ +! #ifdef USG + if (!unknown_children_possible) + { + #endif +--- 398,404 ---- + if (c == 0) + { + /* An unknown child died. */ +! #if defined(USG) || defined(LINUX) + if (!unknown_children_possible) + { + #endif +*************** +*** 407,413 **** + ignore_errors_flag); + else + error ("%s finished.", buf); +! #ifdef USG + } + #endif + } +--- 409,415 ---- + ignore_errors_flag); + else + error ("%s finished.", buf); +! #if defined(USG) || defined(LINUX) + } + #endif + } +diff -cr gmake-3.62//main.c gmake-linux//main.c +*** gmake-3.62//main.c Mon Sep 9 23:36:15 1991 +--- gmake-linux//main.c Mon Mar 23 19:50:35 1992 +*************** +*** 321,329 **** +--- 321,333 ---- + FATAL_SIG (SIGDANGER); + #endif + FATAL_SIG (SIGFPE); ++ #ifdef SIGBUS + FATAL_SIG (SIGBUS); ++ #endif + FATAL_SIG (SIGSEGV); ++ #ifdef SIGSYS + FATAL_SIG (SIGSYS); ++ #endif + FATAL_SIG (SIGTERM); + #ifdef SIGXCPU + FATAL_SIG (SIGXCPU); +diff -cr gmake-3.62//make.h gmake-linux//make.h +*** gmake-3.62//make.h Sat Oct 26 21:19:59 1991 +--- gmake-linux//make.h Mon Mar 23 20:18:30 1992 +*************** +*** 205,211 **** + extern void user_access (), make_access (), child_access (); + + +! #if defined(USG) && !defined(HAVE_VFORK) + #define vfork fork + #define VFORK_NAME "fork" + #else /* Have vfork or not USG. */ +--- 205,211 ---- + extern void user_access (), make_access (), child_access (); + + +! #if (defined(USG) || defined(LINUX)) && !defined(HAVE_VFORK) + #define vfork fork + #define VFORK_NAME "fork" + #else /* Have vfork or not USG. */ +*************** +*** 232,238 **** + extern char *ctime (); + #endif /* GNU C library or POSIX. */ + +! #if defined(USG) || defined(POSIX) && !defined(__GNU_LIBRARY__) + extern char *getcwd (); + #ifdef PATH_MAX + #define getwd(buf) getcwd (buf, PATH_MAX - 2) +--- 232,238 ---- + extern char *ctime (); + #endif /* GNU C library or POSIX. */ + +! #if defined(USG) || defined(LINUX) || defined(POSIX) && !defined(__GNU_LIBRARY__) + extern char *getcwd (); + #ifdef PATH_MAX + #define getwd(buf) getcwd (buf, PATH_MAX - 2) + diff --git a/Linux-0.95/binaries/usr.bin/joe.tar.Z b/Linux-0.95/binaries/usr.bin/joe.tar.Z new file mode 100644 index 00000000..9830b0b4 Binary files /dev/null and b/Linux-0.95/binaries/usr.bin/joe.tar.Z differ diff --git a/Linux-0.95/binaries/usr.bin/tar b/Linux-0.95/binaries/usr.bin/tar new file mode 100644 index 00000000..6643a486 Binary files /dev/null and b/Linux-0.95/binaries/usr.bin/tar differ diff --git a/Linux-0.95/binaries/usr.bin/tex.tar b/Linux-0.95/binaries/usr.bin/tex.tar new file mode 100644 index 00000000..3054f903 Binary files /dev/null and b/Linux-0.95/binaries/usr.bin/tex.tar differ diff --git a/Linux-0.95/binaries/usr.bin/textutils-1.2.tar.Z b/Linux-0.95/binaries/usr.bin/textutils-1.2.tar.Z new file mode 100644 index 00000000..0e004bc5 Binary files /dev/null and b/Linux-0.95/binaries/usr.bin/textutils-1.2.tar.Z differ diff --git a/Linux-0.95/binaries/usr.bin/uucp-1.03-bin.tar.Z b/Linux-0.95/binaries/usr.bin/uucp-1.03-bin.tar.Z new file mode 100644 index 00000000..deee276e Binary files /dev/null and b/Linux-0.95/binaries/usr.bin/uucp-1.03-bin.tar.Z differ diff --git a/Linux-0.95/binaries/usr.bin/xcomm.tar.Z b/Linux-0.95/binaries/usr.bin/xcomm.tar.Z new file mode 100644 index 00000000..a341eb0d Binary files /dev/null and b/Linux-0.95/binaries/usr.bin/xcomm.tar.Z differ diff --git a/Linux-0.95/binaries/usr.bin/zip-bin.tar.Z b/Linux-0.95/binaries/usr.bin/zip-bin.tar.Z new file mode 100644 index 00000000..14435681 Binary files /dev/null and b/Linux-0.95/binaries/usr.bin/zip-bin.tar.Z differ diff --git a/Linux-0.95/binaries/usr.games/banner.Z b/Linux-0.95/binaries/usr.games/banner.Z new file mode 100644 index 00000000..be2a95f8 Binary files /dev/null and b/Linux-0.95/binaries/usr.games/banner.Z differ diff --git a/Linux-0.95/binaries/usr.games/dkbtrace.tar.Z b/Linux-0.95/binaries/usr.games/dkbtrace.tar.Z new file mode 100644 index 00000000..4acc0df3 Binary files /dev/null and b/Linux-0.95/binaries/usr.games/dkbtrace.tar.Z differ diff --git a/Linux-0.95/binaries/usr.games/dungeon.tar.Z b/Linux-0.95/binaries/usr.games/dungeon.tar.Z new file mode 100644 index 00000000..f68f1246 Binary files /dev/null and b/Linux-0.95/binaries/usr.games/dungeon.tar.Z differ diff --git a/Linux-0.95/binaries/usr.games/gnuchess-3.1.tar.Z b/Linux-0.95/binaries/usr.games/gnuchess-3.1.tar.Z new file mode 100644 index 00000000..a11846fc Binary files /dev/null and b/Linux-0.95/binaries/usr.games/gnuchess-3.1.tar.Z differ diff --git a/Linux-0.95/binaries/usr.games/mille.tar.Z b/Linux-0.95/binaries/usr.games/mille.tar.Z new file mode 100644 index 00000000..d1f0e1c3 Binary files /dev/null and b/Linux-0.95/binaries/usr.games/mille.tar.Z differ diff --git a/Linux-0.95/binaries/usr.games/nh3p10bin.tar.Z b/Linux-0.95/binaries/usr.games/nh3p10bin.tar.Z new file mode 100644 index 00000000..155be534 Binary files /dev/null and b/Linux-0.95/binaries/usr.games/nh3p10bin.tar.Z differ diff --git a/Linux-0.95/docs/CHANGES-0.95a b/Linux-0.95/docs/CHANGES-0.95a new file mode 100644 index 00000000..3690f654 --- /dev/null +++ b/Linux-0.95/docs/CHANGES-0.95a @@ -0,0 +1,140 @@ +CHANGES IN THE LINUX v0.95a ROOT DISKETTE +Jim Winstead Jr. - March 17, 1992 + +This file mostly contains info about the changes in the root diskette +from Linux v0.95/0.12 to Linux v0.95a. + +CHANGES + +With the release of Linux v0.95a, the maintenance of the root diskette +has been assumed by Jim Winstead Jr. (jwinstea@jarthur.Claremont.EDU). +This means there are a few large changes between the Linux 0.95 and +0.12 root floppies and the Linux 0.95a root floppy. These are +detailed (as much as I remember them) below: + +- 'bash' has been replaced with 'ash', the BSD 4.3 /bin/sh. This + freed up nearly 200k on the root floppy. However, there are + some problems with 'ash' that haven't been resolved: + + - sometimes the backspace key will not work on a virtual + console. I've found that it usually works on all _but_ one + console, so this is only a minor hinderance. + + - 'ash 'supports BSD-style job control, and this has not yet been + adapted to Linux's more POSIXish job control. This means + that 'ash' does not yet support job control, but it's being + worked upon. + +- 'tar' and 'compress' are back on the root floppy. 'tar' is + compressed, and both utilities are in /bin. + +- 'pfdisk', a disk partitioner, was added to the root floppy. + This makes it (almost) possible to install Linux on a machine + without looking at another OS. + +- the file pager 'more' has been added to the floppy. This was + added because of the addition of some documentation files on + the root floppy. + +- 'cat' has been added to /bin. + +- many utilities have been moved from /usr/bin to /bin, to + conform to the Linux Directory Structure Standard (v1.0). + These utilities are ones that are 'vital to the restoration of + other file systems in the case of a corrupting crash.' + +- 'init' and 'update' have been moved to /etc from /bin. This + was done because neither program should be executed from the + command line by any user, including root. (That means don't + put /etc in your PATH!) This has been a matter of some + controversy, but this is how it will stand until the Linux + Standards mailing list/committee decides otherwise. + +- tty64, tty65, etc, have been renamed to ttys1, ttys2, etc. + +- the directory /INSTALL was added, which contains some + documentation, and three simple shell scripts to make + installing Linux on a hard drive partition easier. These are: + + - 'mktree', which makes a directory tree on the specified + mounted device. + - 'mkdev' which creates the standard devices in the dev + directory of the specified mounted device + - 'install' which installs the programs on the root diskette + to the specified mounted device + + These programs will normally be called with ' /mnt'. + +- rootdev is different than the one on v0.95. A couple of days + after the release of 0.95, a program called 'rdev' was posted + to alt.os.linux that duplicated and extended the functionality + of rootdev. This was renamed to rootdev and replaces the old + rootdev. + +- agetty was renamed to getty, to be consistent with common Unix + practice. + +- an improved fdisk was added that correctly reports extended + partitions, (Thanks to Linus!) + +- /dev is complete, or at least more complete than the last few + releases of the root diskette, which always seemed to be a + major complaint. :) + +- /etc/issue and /etc/motd have been expanded to be a little + more informative. (Yeah, I know, big deal! :) + +- chgrp was removed. You can use chown to get the same effect, + but you just have to specify an owner, too. + +Many of these changes were discussed on alt.os.linux, or the Linux +Standards group, so they may look familiar. + +If you have questions, problems, or complaints about the root +diskette, either post to alt.os.linux, or send mail to me at +jwinstea@jarthur.Claremont.EDU. + +If you have questions, problems, or complaints about the boot diskette +or the kernel itself, post to alt.os.linux or send mail to Linus +Torvalds at torvalds@cc.helsinki.fi. + +Remember, the only stupid questions are the ones you don't ask. + +FUTURE CHANGES + +I'm already anticipating some changes for the next release, so here's +a sneak preview: + +- shared libraries. These are currently in alpha testing, and + will hopefully free up some more room on the root floppy for + more goodies. + +- a generic mtools might be added to the root floppy. + +- a better fdisk to replace the current fdisk/pfdisk pair. You + won't need to know your drive's geometry for this, and it will + know about Linux extended partitions. + +- an improved sh. I'm working on the backspace problem, and + adding job control. I'm also going to look at using the GNU + readline library for input, as long as it doesn't add + substantially to the size of sh. + +- init/getty/login may be removed from the root floppy. The + main reason they'll still on there is the backspace problem + with ash. + +- improved installation documentation. People have started work + on this already - read alt.os.linux for previews. + +- more robust installation scripts. The current ones are quick + and dirty, and work well, but I'd like to add better ones. + +- miscellaneous utilities added. I'd really like to add an + editor to the root disk, but I haven't found one small enough. + Any suggestions? + +- various other things that I can't remember right now. + +Again, mail your questions, comments and suggestions about the root +diskette to me at jwinstea@jarthur.Claremont.EDU. diff --git a/Linux-0.95/docs/FAQ-0.95a b/Linux-0.95/docs/FAQ-0.95a new file mode 100644 index 00000000..9c2797d5 --- /dev/null +++ b/Linux-0.95/docs/FAQ-0.95a @@ -0,0 +1,1302 @@ + + +The originall FAQ 1st version was posted in Dec. 19, by Robert Blum, + +Most credits of this work to Linus, Robert and Ted, the rest was +either on the list posted by many (real) activists, not me ;-), either +in some other news groups, or else by direct posting to me (thanks +Humberto, Dan, Michael, Drew). I haven't systematically copyrighted +them, so thanks to every one who participated even indirectly to this +FAQ. + +[The last-change-date of this posting is always "two minutes ago". :-)] + +This is the introduction to a list of frequently asked questions (FAQ +for short) about Linux with answers (Yeap!). This article contains a +listing of the sections, followed by the question/answer part. + +This FAQ is supposed to reduce the noise level ;-) in the alt.os.linux +newsgroup (and also the 'linux-activists' mailing list), and spare the +time of many activists. I will post it twice a month, since there are +more and more new incomers, and new features. + +BTW I think this FAQ should be available at the main Linux sites in +the doc directory (have you read this Ari, Robert, Ted/Michael ?). So +I will send a copy to the main sites. + +Please suggest any change, rephrasing, deletions, new questions, +answers ... +Please include "FAQ" in the subject of messages sent to me about FAQ. +Please use corsini@labri.greco-prog.fr whatever will be the From part +of this message. + + +Thanks in advance, + Marc + +Future Plan: + - verification/location/organization for files available + via FTP (I've tried what a mess!!) + - cross posting this to news.answers as soon as comp.os.linux + is created. + - reorganization of the FAQ. I don't know how, but I feel it's + needed, any help appreciated. + +================================8<=====8<============================== +CONTENTS + I. LINUX GENERAL INFORMATION + II. LINUX USEFUL ADRESSES + III. INSTALLATION and SECURITY + IV. LINUX and DOS + V. SOME CLASSICAL PROBLEMS + VI. INSTALLATION HINTS + VII. FEATURES + VIII. MORE HINTS + +I. LINUX GENERAL INFORMATION +============================= + +QUESTION: What is linux? + +ANSWER: Linux is a small unix for 386-AT computers, that has the added +advantage of being free. It is still in beta-testing, but is slowly +getting useful even for somewhat real developement. The current +version is 0.95a, date: March 17th 1992. The previous version v0.95 +(March 7th) had some bugs, please do not use it anymore. + + + Linux 0.95(a) is a freely distributable UNIX clone. It implements a +subset of System V and POSIX functionality. LINUX has been written +from scratch, and therefore does not contain any AT&T or MINIX +code--not in the kernel, the compiler, the utilities, or the +libraries. For this reason it can be made available with the complete +source code via anonymous FTP. LINUX runs only on 386/486 AT-bus +machines; porting to non-Intel architectures is likely to be +difficult, as the kernel makes extensive use of 386 memory management +and task primitives. + + +QUESTION: What is the current state of Linux? + +ANSWER: do "finger torvalds@kruuna.helsinki.fi", or read the +alt.os.linux newsgroup. + + +QUESTION: I've just heard about linux, what should I do to get it? + +ANSWER: First read all this FAQ, and the INFO-SHEET monthly post, then +go to the nearest ftp site (see below), download the Images there are +two a rootimage and a bootimage (in general in the images directory), +download the INSTALL and RELNOTES files. Find the rawrite utility +(for example at tsx-11 it's in /pub/linux/INSTALL), then rawrite the +images on HIGH density floppies (5.25 or 3.5), finally boot on the +root diskette and that's it. +BTW From another Unix system a "dd" works fine. + +After playing a while, you should want to install linux on HD (there +are scripts on the v0.95a images for that purpose), see also section +III for INSTALLATION. Then you will need +a compiler (gcc) and utilities, all can be found at the different +places described in section II below. + + +QUESTION: Does it run on my computer? + +ANSWER: Linux has been written on a clone-386, with IDE drives and a +VGA screen. It should work on most similar setups. The harddisk should +be AT-standard, and the system must be ISA. A high density floppy +drive -- either 5".25 or 3".5 + +IDE and MFM seem to work with no problem. It works, also, for some +ESDI drive (Joincom controller with Magtron drive after you have +commented out the "unexpected hd interrupt"-message from hd.c). There +exists a high-level SCSI driver, under which low-level drivers are +placed; a ST-01/ST-02 low driver has been completed + +Otherwise the requirements seem relatively small: a 386 (SX, DX or any +486). Any video card of the following: Hercules, CGA, EGA, (S)VGA. + +It needs at least 2M to run, and 4M is definitely a plus. It can +happily use up to 16M (and more if you change some things). + + +QUESTION: Why the suggested 4Meg, for Linux? + +ANSWER: Linux uses the first 640k for kernel text, kernel data and +buffercache. Your mother board may eat up 384K because of the chipset. +Moreover there is: init/login, a shell, update possibly other daemons. +Then, while compiling there is make and gcc (1.39 ~400k; 2.00 ~700k). +So you don't have enough real memory and have to page. + + +QUESTION: How would this operate in an OS/2 environment? + +ANSWER: Fine. + + +QUESTION: Will linux run on a PC or 286-AT? If not, why? + +ANSWER: Linux uses the 386 chip protected mode functions extensively, +and is a true 32-bit operating system. Thus x86 chips, x<3, will +simply not run it. + + +QUESTION: Will Linux run on a 386 Laptop? + +ANSWER: It works for some at least. + + +QUESTION: How big is the 'complete' Linux package? + +ANSWER: Well, the boot and root image diskettes are about 750k +compressed. The kernel sources are about 200k compressed, and the +libc sources are another 170k compressed. The GNU C compiler is 670k, +and the other miscellaneous unix utilities are probably a bit over a +megabyte. + +Now add sources to whatever you want to port and compile yourself. +The sources to GNU emacs are about 3 megabytes, compressed. Groff (a +troff replacement) is just over 1 megabyte. + +If you think this is big, remember that the OS/2 2.0 Limited +Availability release is 20 1.44 megabyte diskettes. + + +QUESTION: (Dan) How long has Linux been publicly available? + +ANSWER (partial): Few months, v0.10 went out in Nov. 91, v0.11 in Dec. +and the current version 0.95a is available since March 17th 92. But even +it is pretty recent it is quite reliable. There are very few and small +bugs and in its current state it is mostly useful for people who are +willing to port code and write new code. +As Linux is very close to a reliable/stable system, Linus decides that +v0.13 will be known as v0.95 + +QUESTION: What's about the copyright of linux. + +ANSWER: This is an except of the RELEASE Notes v.095a: Linux-0.95a is +NOT public domain software, but is copyrighted by Linus Torvalds. The +copyright conditions are the same as those imposed by the GNU +copyleft: get a copy of the GNU copyleft at any major ftp-site (if it +carries linux, it probably carries a lot of GNU software anyway, and +they all contain the copyright). + + +QUESTION: Should I be a UNIX and/or a DOS wizard to install/use Linux? + +ANSWER: Not at all, just follow the install rules, of course it will be +easier for you if you know things about Unix. Right now Linux is used +by more than 400 persons, very few of them enhance the kernel, some +adds/ports new soft, most of us are only (but USEFUL) beta testers. +Last but not least, various Linuxers work on manpages, newuser_help, +file-system organization. So join us and choose your "caste" + + +QUESTION: What are the differences, pros and cons compared to Minix ? + +ANSWER (partial): +Cons: +- Linux is not as mature as Minix, there is less working software right now. +- Linux only works on 386 and 486 processors. +- Linux needs 2M of memory just to run, 4M to be useful. +- Linux is a more traditional unix kernel, it doesn't use message passing. + +Pros: +- Linux is free, and freely distributable, BUT copyrighted. +- Linux has some advanced features such as: + - Memory paging with copy-on-write + - Demand loading of executables + - Page sharing of executables + - Multi-threaded file system + - job control and virtual memory, virtual consoles and pseudo-ttys. +- Linux is a more traditional unix kernel, it doesn't use message +passing. + + +QUESTION: Does Linux use TSS segments to provide multitasking? + +ANSWER: Yes! + + +QUESTION: If my PC runs under Linux, is it possible to ftp, rlogin, +rsh etc.. to other Unix boxes? + +ANSWER: Not yet, but kermit has been ported to Linux, and the ka9q too. + + +QUESTION: Does linux do paging? Can I have virtual memory on my small +machine? + +ANSWER: Linux0.95(a) does do paging in a better way than Linux0.12. + + +QUESTION: Can I have tasks spanning the full 4GB of addressable 386 +memory? No more 64kB limits like in coherent or standard minix? + +ANSWER: Linux does limit the task-size, but at a much more reasonable +64MB (MEGA-byte, not kilos), so bigger programs are no problem. + + +QUESTION: Does the bigger program sizes mean I can run X? + +ANSWER: X is not (yet) ported to linux, and I hope it will be some day, +people are working hard on it but it's big, and wants a lot from +the system. + + +II. LINUX USEFUL ADRESSES +========================= + +QUESTION: Where can I get linux? + +ANSWER: Linux can be gotten by anonymous ftp from + nic.funet.fi (128.214.6.100): + directory /pub/OS/Linux + Tupac-Amaru.Informatik.RWTH-Aachen.DE (137.226.112.31): + directory /pub/msdos/replace + tsx-11.mit.edu (18.172.1.2): + directory /pub/linux + ftp.eecs.umich.edu (141.212.99.7): + directory linux + src.doc.ic.ac.uk (146.169.3.7): + directory /pub/os/Linux + hpb.mcc.ac.uk (130.88.200.7): + directory pub/linux + ustsun.s.u-tokyo.ac.jp (133.11.11.11): + directory misc/linux + banjo.concert.net (192.101.21.6): + directory pub/Linux/mirrors + +You might want to check out which of these is the most up-to-date. + +If you don't have ftp-capability, you are in trouble. See next Q/A. If +you have no uncompress utility, there are a lot even for DOS, have a +look on SIMTEL, or else use facilities provided by some sites to +uncompress for you. Don't do that if you can, because it's lengthy, +expensive and causes troubles to other users on ftp sites. + + +QUESTION: I do not have FTP access, what can I do to get linux? + +ANSWER: Try to contact a friend on the net with those access, or try +mailserver/ftpmail server otherwise contact tytso@ATHENA.MIT.EDU. You +might try mailing "mailserver@nic.funet.fi" with "help" in the body of +the mail. If you choose ftpmail server (example: ftpmail@decwrl.dec.com), +with "help" in the body, the server will send back instructions and +command list. As an exemple to get the list of files available at tsx-11 +in /pub/linux send: + + mail ftpmail@decwrl.dec.com + subject: anything + reply + connect tsx-11.mit.edu + chdir /pub/linux + dir -R + quit + +QUESTION: Is there a newsgroup or mailing-list about linux? Where can +I get my questions answered? How about bug-reports? + +ANSWER: alt.os.linux is formed, and comp.os.linux is on the way, for +those who can't access to the news you can ask for digest to: +Linux-Activists-request@NEWS-DIGESTS.MIT.EDU. On the other hand, mail +sent to Linux-Activists@NEWS-DIGESTS.MIT.EDU are posted to +alt.os.linux + +DO NOT mail "I want to [un]subscribe" to the newsgroup, use +the request-address. IF not your mail-box will be over-crowded by +activists. + +Questions and bug-reports can be sent either to the newsgroup or to +"torvalds@kruuna.helsinki.fi", depending on which you find more +appropriate. Moreover there is a BUGLIST file available in the +different main site (at least you can find it at tsx-11, in +pub/linux/patches/BUGLIST). + +BTW People are working on the organization of Linux, this is done on +a separate mailing-list. + +linux-standards: Discussion of distribution and directory standards +for the Linux operating system, including directory structure, file +location, and release disk format. + +Requests to be added to this list must be sent to: + linux-standards-request@banjo.concert.net + +QUESTION: Does there exist a place where the traffic of the newsgroup +is kept? + +ANSWER: Yes, on nic and tsx-11 (see the ftp adresses above), and since +12th March, a Gopher server is up at beryl.daimi.aau.dk +(130.225.16.86). The archives go back to Nov. 18. 91 + +III. INSTALLATION and SECURITY +============================== + + +QUESTION: I have copyed all the rootimage stuff on my HD, how can I +use the hard-disk as root? + +ANSWER: There are two ways to answer this: +a) You have download the linux sources and a compiler, in that case +recompile the kernel to make a new boot-floppy according to your +environment. Just have a look in the main Makefile and in +kernel/chr_drv/keyboard.S (notice .S not .s) to set your national +keyboard. +b) You have nothing except the images and DOS, in that case you should +have read the INSTALLATION notices provided at your ftp site, but well: +You have to change the boot image at offset 508. The word (in +386-order, i.e low-byte first) tells the system which device to use as +root: initially it's 0 which means that we want to use a floppy of the +same type as the boot-disk (this is the reason why HIGH density +floppy is required for the boot-image). +In order to use the HD as root, this value has to be changed to point +to the correct device. For that purpose you can download the program +enclosed in INSTALL-0.10 (provided some slight modification according +to the new minor/major numbers) use the program written by Henning +Spruth wich can be found in digest#149 vol1 (there are both the C code +and the uuencoded DOS executable) or else any sector editor. + +QUESTION: How can I be sure I won't be writing over anything +important? I have to use DOS on my machine, and I don't want to +lose any files. + +ANSWER: Back up everything. Just in case. Then, write some easily +recognizable pattern to the partition you have reserved for linux, +using some DOS tool. You can then use "cat /dev/hdX" under linux to +examine which of the partitions you used. + + +QUESTION: Linux mkfs doesn't accept the size I give the device, +although I double-checked with fdisk, and it's correct. + +ANSWER: Be sure you give the size in BLOCKS, ie 1024 bytes, not +sectors. The mkfs doesn't work for very big partition (over than 64 +Megs). Also, make doubly certain that you have the correct partition. + +There are a few rules about this: /dev/hda (under linux0.95a) corresponds +to /dev/hd0 (under minix) and /dev/hdb (linux0.95a) to /dev/hd5 +(minix). DO NOT USE THEM, they are the whole raw +disk, not partitions. Also if a partition is on drive 1 under minix +(ie /dev/hd1-4), it is drive 1 under linux as well. Moreover, there +is no real consensus on whether partition #1 is the first partition on +the disk, or is the first entry in the partition table. Some parition +programs sort this information on the screen only, some will write the +sorted information back to the hard disk. Linux assumes that the +first entry is hda1, and so if some utility starts sorting/reordering +the table these things can change. Moreover, use very carefully extended +partition they are still in beta-test (this is in the installation notes). + +REMARK Minix does some reordering. + +A useful hack is to make each of your partitions a different size. +Then after any editting or possible change to the partition table you +can boot a floppy system and run fdisk (linux's, not DOS) to see if +the assignments still hold. + + +QUESTION: I have a one partitionned 40Mb disk. If I run mkfs, what +happens? + +ANSWER: If you do that, you will have an empty 40Mb Linux file system. +You should, at least, make on your hard disk, one partition per +operating system you want to use. + + +QUESTION: I mounted the linux filesystem, and copied the files from +the root-disk to the harddisk. Now I cannot find them any more, and +somethimes linux dies with a "panic: trying to free unused inode". + +ANSWER: You have probably forgot to sync before rebooting. Linux, like +all unices, use a "buffer cache" to speed up reads and writes to disk. +On a machine that has enough memory, this buffer-cache is 1.5MB, and +if you forget to sync before exiting, it may not be fully written out +to disk. Re-mkfs and re-install (or try to use the preliminary fsck, +but remember that although fsck tries to correct the faults it finds, +it may fail.) + + +IV. LINUX and DOS +================= + +QUESTION: Is it possible to access to DOS world from Linux + +ANSWER: Yes, there is the mtools package (with patches for devices.c) +The original sources of mtools can be found at any places not only at +nic, tupac and tsx-11, and the patches for Linux (with fix for big DOS +partitions are in the directory patches or ports). Moreover you should +download the file patch.Z to apply patches :) +It is possible to find the compiled mtools stuff at mcc (see above for +the adress) + + +QUESTION: the mtools package won't work. I get an ENOENT error message +for all devices. + +ANSWER: mtools needs to be told which device to look for. Use 'ln' or +'mknod' to create a special file called "/dev/dosX", where X is A, B, +C, X or Y. A and B are for floppies (12 bits), C is for hard disk and +X, Y for any. This file should point to the device you want to read. +About the minor/major pair have a look in section INSTALLATION HINTS. + + +QUESTION: What is as86.tar.Z ? + +ANSWER: It's the port of Bruce Evans' minix assembler, you need it to +be able to recompile Linux at your convenience. In fact this is only +used for boot/setup.s and boot/bootsect.s +BTW as86 should not work on keyboard.S, instead, you must use gcc -E +and then (g)as. + + +QUESTION: Turbo (Microsoft) Assembler won't compile the Linux boot +code. In fact, some of the opcodes in these files look completely +unfamiliar. Why? + +ANSWER: The Linux boot codes are written in Bruce Evans' minix +assembler, which has the same opcodes as the original minix assembler +ported to linux get as86.tar.Z Anyway there are a few differences +between these and normal DOS assemblers: + + - No segments - everything is in the same segment (at least in the + bootsectors and setup, as they don't use the .data segments) + + - mov[b|w|l] are shorter versions of mov ax,[byte|word|long] ptr +[XXX]. + This is how unix assemblers normally give the size (byte, word or +long). + Gas has similar constructs. + + - There is no "jmp short", the opcodes are "j" for a short jump and + "jmp" for a long one. + + - "jmpi" is a jump with a segment:offset pair. I don't know how this +is + written in DOS assembly. + + +V. SOME CLASSICAL PROBLEMS +========================== + +QUESTION: While running du I get "Kernel panic: free_inode: bit +already cleared". Also, du produces a ENOENT error for all the files +in certain of my directories. What's going on? + +ANSWER: These are both consistent with a bad file-system. That's +relatively easy to produce by not syncing before rebooting, as linux +usually has 1.5MB of buffer space held in memory (unless you have <=4M +RAM, in which case the buffers are only about 0.5MB). Also linux +doesn't do anything special about the bit-map blocks, and as they are +used often, those are the thing most likely to be in memory. If you +reboot, and they haven't been written to disk ... + +Just do an fsck on the device, the -a flag might repair it otherwise, +the only thing to do is to reinstall the filesystem from the Images. + +A sync is done only every 30 seconds normally (standard unix +practice), so do one by hand (some people think you should do 3 syncs +after each other, but that's superstition), or by logging out from the +startup-shell, which automatically syncs the system. Unmounting a +filesystem also syncs it (but of course you can never unmount root). + +Another (sad) possibility is that you have bad blocks on your disk. +Not very probable, as they would have to be in the inode-tables, just +a couple of blocks in size. Again there aren't programs available to +read a disk for bad sectors and put them in some kind of +"bad-sector-file". On IDE drives this is no problem (bad sectors are +automatically mapped away). + + +QUESTION: How can I partition my hard-drive to use Linux? + +ANSWER: There are (at least) two ways to answer this. The easy way is +probably to use a program which will do it for you, such as the MS-DOS +fdisk, Minix fdisk, Xenix/Unix fdisk, or programs such as edpart.exe +or part.exe. + +On the other hand, you can use a disk editor and modify the contents +of the partition table directly. This has been already done, and an +extensive explanatory note can be found in the mailing-list archives +(25th Jan. 92). You must also edit the bpb on the Dos partition you +are shrinking, otherwise Dos will step on Linux. + +BTW It might be useful to set three (3) separated partitions for +Linux, one for the root, another one for the usr and a third one for +swap, as an illustration, my root partition is 10Meg, the usr is 22Meg +and the swap partition is 8Meg (twice the size of RAM on my box). As +an experience I have used MS-DOS fdisk to partition my two hd and got +no peculiar difficulties. +You can, as long as you stay within the 64MB per filesystem +limit, have swap, root, etc, ... all on there. + +QUESTION: What must I do to mkfs a floppy? + +ANSWER: blocks are of size 1K so 1.44 floppy is 1440 blocks. The +floppy has to be formatted before this will work. + + +QUESTION: When I run kermit under Linux, I get "Warning, Read access +to lock directory denied". What am I doing wrong? + +ANSWER: Nothing, you just need to create /usr/spool/uucp, which is +where kermit like to lock files. + + +QUESTION: du seems buggy when i used it the number of disk occupation +is wrong. + +ANSWER: Take care, if you want size in kbytes use the -k flags. + + +QUESTION: du works just fine on directories, except on / and /dev, +moreover "ls -l" returns either big or negative number on /dev. Why? + +ANSWER: This is a "feature" added in Linux 0.12; it was originally +present in Minix; more specifically, when you stat a device file +belong to a block device, it will return the maximum size of the block +device in the st_size member of the stat structure. If you don't like +it, it's very simple to patch it out. Look in the fs/inode.c, in the +subroutine read_inode(). + + +QUESTION: When I try to (un)compress many files in one command, the +command partially fails? + +ANSWER: This is a bug, many partial fixes are floating around but .. +You can solve it by a bash command "for i in whateverfiles;do +compress $i; done". Another possibility is to download the +compress-fixed.tar file. + + +QUESTION: I can do this as root but not as non-root, is it a bug? + +ANSWER: Except for the make utility, the problem is caused by an +incorrect permission flag. The most common problems are about /tmp +which should be 777 and /dev/ttys? which might be 766. So as root do + + chmod 777 /tmp ; chmod 766 /dev/ttys? + + +QUESTION Sometimes, I get "mount can't open lock file"; what does this +means? + +ANSWER: This can happened for two reasons: +A) You try to mount something as non-root. In that case you can either +retry as root, or set the setuid bit to mount. +B) You are root. mount wants to open /etc/mtab and /etc/mtab~ - the +first one for reading, the second as lock file. If there is already a +mtab~ remove it. This can happen if you used once gnuemacs on mtab. + + +VI. INSTALLATION HINTS +====================== + +QUESTION: Where can I find the basic starting help? + +ANSWER: You have to download the INSTALL notes, and more specially +the 0.11, 0.12 and the current one 0.95(a). Pretty soon, a special +help for beginners will be available on the net. + + +QUESTION: I've got all the things on site ??? but I don't know what +goes where. + +ANSWER: include.tar.Z goes to /usr/include; system.tar.Z contains +the latest sources of the +system files (mkswap, mkfs, fsck and fdisk). In version 0.12 +utilbin.tar.Z has been replaced by fileutil.tar.Z and utils.tar.Z +which contains a new tar to handle the symbolic links, make, uemacs +kermit and minor programs (sed,...). Other utilities have been ported +separately. + + +QUESTION: I don't know how to install gcc stuff, is there special places? + +ANSWER: It depends on the release of gcc you are using. Right now +there are 3 packages : the original one gccbin.tar.Z contains all +the gcc-1.37 binary distrib; recently the gcc-1.40 has been ported, +it's in newgcc.tar.Z and a few days ago the BETA version of gcc-2.0 +Choose yours + +A) gccbin.tar.Z goes in /usr/local/lib except gcc which goes in +/usr/local/bin. Moreover each gcc-xxx of /usr/local/lib should be +linked with gxxx and xxx in /usr/local/bin. + +B) newgcc.tar.Z goes in /usr, then uncompress and untar it. Files are +directed to /usr/lib, /usr/include and /usr/bin. You have to link ar, +as, ld with gar, gas and gld, this will prevent some error while using +make (especially whilst re-compiling Linux kernel). More information can +be found in section VIII. + +C) gcc-2.0 is splitted in 2 files 2lib.tar.Z and 2misc.tar.Z, to +install them do the following: +cd /usr +tar xvofvz 2misc.tar.Z + +read the FAQ in /usr/gcc2/install. Then + +cd /usr +tar xvovfz 2lib.tar.Z + + +QUESTION: When I use the images, and i type "tar xvf ..." I got +"command not found". What did I wrong? + +ANSWER: Nothing, in the distribution of 0.95 there is no tar (due to +lack of place); you should get the 0.12 images where the tar is in +compressed form (lack of place). You have first to copy tar.Z on +another disk/diskette and uncompress it, this command is available +on your diskettes. +BTW tar and compress are back in v0.95a distrib. + +QUESTION: It seems that $#@! ported on linux don't run correctly + +ANSWER: Possible, but check first if the size of your file corresponds +to the one on the ftp sites, if it is then check the BUGLIST available +on the main linux sites. If the bug is not reported, do a complete +report of the error, try to correct it and send your result to +johnsonm@stolaf.edu. + + +QUESTION: Does anyone port this to linux?, if not i'll compile it + +ANSWER: First check on the sites, have a look to the info-sheet +monthly post and also available on sites. Have a look in the "old" +digest files and mail-archives of linux-activists, these are kept at +least at tsx-11 and nic possibly at tupac. Look also at the GNU(*) +utilities to see if someone has already written a freely distribuable +version. Ask then on the list/news. + + +(*) GNU stands for GNU's Not Unix, which (besides being a recursive +acronym) is a project started by the Free Software Foundation (the FSF) +to write a freely distributable version of Unix. The GNU kernel is +named HURD, and is based on Mach. It is currently being written, and is +not yet done. Many of the GNU utilities, however, are completed and are +much more functional than the original Unix utilities. Since they are +freely available, Linux is using them as well. + + +QUESTION: I've ported *** to Linux, what should i do to add it in the +standard distribution? + +ANSWER: Read first the previous Q/A, then to make something available to +others you have to post it (with cdiffs of the source, a short README) +in the incoming directory of one of nic,tupac,tsx-11, then drop +a short note to the list/group and to the site advisor. +On nic it's arl@sauna.cs.hut.fi (Ari Lemmke) +On tupac it's blum@cip-s01.informatik.rwth-aachen.de (Robert Blum) +On tsx-11 it's ftp-linux@tsx-11.mit.edu (Ted Ts'o and Michael Johnson) + + +QUESTION: I want to port *** to Linux, what are the flags? + +ANSWER: Recall that Linux implements subset of SYSV and POSIX, so +-DUSG and -DPOSIX work in general. Moreover throw away most of the ld +flags such as -ltermcap, -lg, since the libg.a and libtermcap.a are +missing. + + +QUESTION: Linux lacks on ****/ Linux has a bug in ***, what are the +rules to enhance/correct the kernel? + +ANSWER: Before anything check if some one else is working on that +subject, contact those people, since end february a buglist (thanks to +Michael Johnson) is kept on the major sites. Test your improvment (it +should work is NOT enough), then send the patches in cdiffs form to +Linus and/or the list, moreover the localization must be clear. This +does NOT mean that bug-reports and patches are not accepted. Moreover, +you should sent a brief note to Michael: johnsonm@stolaf.edu + + +QUESTION: I seem to be unable to compile anything with gcc. Why? + +ANSWER: If you have only 2 MB RAM, gcc will die silently without +compiling anything. You must have at least 4 MB to do compilations + +BTW Since swapping is possible, I have heard that compilation works +with only 2Meg and a lot disk traffic :) Isn't it great? + + +QUESTION: I'm using a program that uses signal handlers which are +installed using sigaction() with the SA_NOMASK, and they get a general +protection error right after the signal handler tries to return. +What's going wrong? + +ANSWER: You are using a libc.a that has an out-of-date signal.o and +sig_restore.o file, and they don't know how to deal with SA_NOMASK. +(The one in gccbin.tar.Z is out-of-date). Get the new libc.a and put +it in /usr/lib or /usr/local/lib. Again check your compiler version + + +QUESTION: gcc complains about not finding crt0.o and the system +include files What am I doing wrong ? + +ANSWER: The include files normal place is in /usr/include. lib*.a and +*.o should be in /usr/lib or /usr/local/lib + + +QUESTION: While compiling some GNU packages gcc chokes on regex.c with +an insn code, what can I do? + +ANSWER: There is a little bug in the port of gcc-1.37, this will be +corrected on the port of v2.0 (with g++). Right now throw away the -O +flag (to compile regex) and every thing will be alright. + +BTW there are some minor bugs with this release of gcc because it was +compiled under linux-0.10, whith odd libraries. These problems should +have disappeared with the new gcc-1.40 package. + +QUESTION: I tried to port a /new/ version of gnu stuff. But in the +linking phase, gcc complains about the missing libg.a. In fact it +depends on the gcc package you use. + +ANSWER: Yes this is well known, throw away the flag -g that's all, +anyway libg.a is /only/ for debugging purpose. + + +QUESTION: What are the device minor/major numbers? + +ANSWER: (early Linus mail Nov. 6th 91, last update Jan. 19th 92) + Memory devices: Major = 1 (characted devices) minor +0 /dev/ram +1 /dev/mem +2 /dev/kmem - not implemented (easy, but I haven't done it) +3 /dev/null +4 /dev/port (implemented, but untested - don't play with it) + +example: "mknod /dev/null c 1 3" + + + Floppy disks: Major = 2 (block devices) + +minor = drive + 4*type, drive = 0,1,2,3 for A,B,C or D-diskette + +type 1: 360kB floppy in 360kB drive (5.25") + 2: 1.2M floppy in 1.2M drive (5.25") + 3: 360kB floppy in 720kB/1.44Mb drive (3.5") + 4: 720kB floppy in 720kB/1.44Mb drive (3.5") + 5: 360kB floppy in 1.2M drive (5.25") + 6: 720kB floppy in 1.2M drive (5.25") + 7: 1.44M floppy in 1.44M drive (3.5") + +Thus minor nr for a 1.44Mb floppy in B is: 1 + 4*7 = 29, and to read +an old 360kB floppy in a 1.2M A-drive you need to use minor= 0 + 4*5 += 20. + +Example: "mknod /dev/PS0 b 2 28" (b for block: 2 for floppy, 28 for +1.44 in A) + + + Hard disks: Major = 3 (block devices) minor +0 /dev/hda - The whole hd0, including partition table sectors +etc. +1 /dev/hda1 - first partition on hd0 +... +4 /dev/hda4 - fourth partition on hd0 +5 /dev/hda5 - Extended partition +64 /dev/hdb - The whole hd1, again including partition table info +65 /dev/hdb1 - first partition on hd1 +... +68 /dev/hdb4 - fourth partition on hd1 +69 /dev/hdb5 - extended partition on hd1 + +NOTE! Be /very/ careful with /dev/hda and /dev/hdb - you seldom need +them, and if you write to them you can destroy the partition tables: +something you probably don't want. The only things that use /dev/hda +are things like "fdisk" etc. + +NOTE 2!! The names for hd's are no longer the same as under minix, +there is a straightforward correspondance, but I think +minix orders the partitions in some way (so that the partition numbers +will be in the same order as the partitions are physically on the +disk). Linux doesn't order anything: it has the partitions in the +same order as in the partition table (ie /dev/hd?1 might be physically +after /dev/hd?2). + +NOTE 3!! Extended partitions are recently detected, use them VERY VERY +carefully. + + Tty's: Major = 4 (character devices) minor +0 /dev/tty0 - general console 1 - +63 - reserved for virtual console +64-127 - reserved for serial io +128- - reserved for pty's + +And more particularly we have: +64 /dev/ttys1 - com1 +65 /dev/ttys2 - com2 +66 /dev/ttys3 - com3 +67 /dev/ttys4 - com4 + + +QUESTION: How to start Linux from drive B? + +ANSWER: There is a DOS utility called boot_b.exe (look at DOS ftp). +Another simple way is to open the box and invert the cables. + +QUESTION: The program boot_b works fine /but/ once the first disk is +read the system go back to the first drive, any hints? + +ANSWER: Yes, change the bootimage in just the same way that you change +it to boot on the hard drive, execept that the major/minor pair is +different. All these information are in the file INSTALL-0.10. +Remember that if you use a sun or other endian machine, you will need +to reverse the byte order when you run the filter program (also in the +same file). + + +VII. FEATURES + +============= + +QUESTION: I've read that linux has virtual consoles, what must I do to +get them? + +ANSWER: Yes there are, you can access them with the left -key +together with -key. With the Linux 0.95a Images distribution, 4 +consoles are available, agetty runs on them. + +BTW: the serial ports are now /dev/ttys1 and /dev/ttys2. tty0 is the +general console. tty128- are reserved to pty's + + +QUESTION: What kind of shell is /bin/sh ? + +ANSWER: Until v0.95 it's the Bourne Again Shell, bash-1.11 and +compilation was straightforward (Linus dixit), just "make" +that's all or nearly. But as the shell comes bigger and bigger the +v0.95a /bin/sh is ash the BSD 4.3 sh. +BTW I think that next time, it will be rc which is much more better +than ash and tiny wrt bash. If you want to test it, it's (at least) at +nic in /pub/unix/shells and the file is rc-1.2.tar.Z . The compilation +is straightforward (just a few things to modify in Makefile and +mksignal). + + +QUESTION: Does there exist a man page for **** ? + +ANSWER: Download man.tar.Z from your favorite linux ftp site, there is +most of the fileutils man page -- either **** or g****, example there +is nothing on ld, but there is for gld :) --, check the whatis +database provided. The files in the cat1 dir are pre-formatted man +pages that the man program can use. + +BTW there is no roff,troff nor nroff for Linux. Cawf 2.0 works just +fine for simple man pages, and a partial ms support too. Quite +recently the port of groff has been done (due to gcc2.0 port), you can +found it (at least on tsx-11) in pub/linux/binaries/usr.bin/groff. + +Moreover Michael Johnson is the coordinator for man pages under Linux, +he is looking for volunteers, so contact him (johnsonm@stolaf.edu). + + +QUESTION: What are the editors available in linux? + +ANSWER: Right now there are uemacs, elvis-1.4, some one (R. Blum) +is working on some other vi clone. The port of emacs 18.57 has been +done by John T Kohl, files can be found at the different sites +at nic it's in the directory xtra +at tsx-11 it's in the directory ports/emacs-18.57. +Also the port of mg (micro gnu) has been done and can be found at +least at athos.rutgers.edu (128.6.4.4) in pub/linux, mg is the binary +and mg.tar.Z is the sources file. You can also find a PD ed, and elvis +has an ex mode. + +QUESTION: Does there exist a printer package for Linux? + +ANSWER: There are lp patches for linux.0.12, which implement a +parallel printer interface and feature a greatly improved driver +design. the patches are in lp.12.tar.Z As I have no printer (yet), I +don't know how good it is. There is nothing yet for 0.95(a), but I've +been told that the patch for v0.12 will fit the v0.95 and possibly the +0.95a. + + +QUESTION: Does there exist a ps for Linux? + +ANSWER: Yes, a very simple one is implemented by default, just press +the scroll-lock key; ctrl-shift-scrollock gives a kind of memory +status. There is also a much more complete ps/memory package it's +ps095.tar.Z. I have tested it, it's GREAT and well documented. + + +QUESTION: It's nice to have the df utility, but it would be nicer if +it would give statistics of the root file system. Would it be +difficult to do? + +ANSWER: surely not, in your file /etc/rc, instead of the line + > etc/mtab +put the following + echo "/dev/hdX (root)" > /etc/mtab +where the X is the hard drive you use as root partition. + + +QUESTION: How do I make swapping work?, when I boot I get the +following message: "Unable to get size of swap device" + +ANSWER: Quite simply, you need the swapon and the mkswap binaries. +Then you can choose between a swap partition or a swap file + + +QUESTION: When I boot I get one of the following messages: +"Unable to find swap signature" or "Bad swap-space bitmap" + +ANSWER: You probably forgot to make your swap-device, use the mkswap +command. + + +QUESTION: How do I know if it is swapping? + +ANSWER: You will notice it :)) First of all, Linux tells you at boot +time, "Adding swap: XXX pages of swap space", and if you start running +out of memory, you will notice that the disk will work overtime, and +things slow down. Generally a 2Meg RAM will make the system swap +constantly while running gcc, 4 Meg will swap occasionnaly when +optimizing big files (and having other things active, such as make). + + +QUESTION: How is it possible to remove a swap file? + +ANSWER: Simply perform a rm on that file, and remove the swapon of +your /etc/rc file. + + +QUESTION: How is it possible to remove a swap device? + +ANSWER: mkfs the device, and remove the swapon of your /etc/rc file. + + +QUESTION: Is there only the %$#@ keyboard ? + +ANSWER: There are Dannish, Finnish, French, German, Uk and US +keyboards. Set it in linux/kernel/chr_drv/keyboard.S, then +compile the kernel again. + + +QUESTION: (special FINNISH/US) I booteed up with the new image and +everything work except that some keyboard keys produce wrong +characters. Does anyone know what is happening? + +ANSWER: images of 0.95a are US product (and so are US-keyboard +oriented), BUT linux sources are FINNISH product, and so the default +keyboard is set to be FINNISH. The solution is in the previous Q/A. + + +QUESTION: Does there exist shared libs ? + +ANSWER: They seem to work. The kernel features are in Linux 0.12 +already. + + +QUESTION: Does Linux permit/support bitmapped graphics on vga/svga +cards? + +ANSWER: No, there is no interface for graphics operations on Linux +(yet). Some work has been done by Orest Zborowski (mmap/munmap, and +vga demonstration). The (un)mmap was patches for 0.12 kernel, but I've +been told that new versions (for 0.95a) will be out in a short while. + +QUESTION: There are a lot of patches available (fd patch, lp patch +login patch ...) can I be fairly confident the subsequent patches will +work? + +ANSWER: This is not true yet for the current version; but it will be +so I kept it :) +No you can't, patching is a real beta tester art :)). People are not +working on the same patched release, so you have to check if the +patches you already applied works on the same kernel part, if not, +/great/, just apply them. If yes, check if there is an order, patch +creator knows that, and (should) try to warn patch user (in other +words: beta tester) otherwise you should edit the patch files (and +possibly make a brief note to others on this list/newsgroup or even a +cdiff) before applying them, another solution is to keep cool and wait +for the next version of Linux where, in general, the modifications +have been done but this behavior is /not/ Linux helpful. + + +QUESTION: I got the patches on some ftp sites, and applied them to the +kernel and tried to compile. It didn't !!. Are the patches buggy? + +ANSWER: Before remake, just do a make clean in the directories +involved by the patches. This will force a rebuild of the .o and .a +files. +If you have a RCS running on your source tree, did you checked a +patched version of the files changed before /any/ CO either by you or +make + +Finally, make sure the patches succeded. Normally, failed patches on a +file FILE will leave a FILE# file. Moreover you will get a "chunk +failed" message. It is possible to capture the output while patching: + + patch -p0 < patchfile | 2>&1 patch.result | more + + +VIII. MORE HINTS +================ + +This part is recent and try to keep track of the different information +that appeared in alt.os.linux and on the list since beginning of +February. I tried to update it for v0.95(a), so there might be some +mistakes. Moreover take care to use the correct library and include +stuff, and the ad-hoc gcc you use !!! + + +QUESTION: How can I backup my Hd under Linux ? + +ANSWER: I know at least two ways. One possibility is tar and mtools, +another possibility is the diskbackup/diskrestore of Diamano Bolla +(digest44 vol. #1) which saves big hd to floppies using the +stdin/stdout. These utilities have been uploaded to the major sites in +file disksplit.tar.Z. +An example usage (Roger Binns) is: + +tar cvf - bin dev usr etc .. | compress | diskbackup + +and to restore: + +diskrestore | uncompress | tar xvf - + + +QUESTION: How to use setterm: for the novice? + +ANSWER:The setterm utility provides access to most of Virtual Consoles +(VCs) functionality. You can set your screen up to blank at 10 +minutes using: + setterm -blank 10 + +You can set colors, and clear the screen. For a full list of commands, +just type "setterm" with no arguments. + +There are a few tricks with the screen dumper can really make VCs go a +long way. Here are a few of the common ones that I use: + + setterm dump + +Dumps the contents of the current VC to screen.dump (in the current dir). + + setterm dump 4 + +Dumps the contents of VC 4 to screen.dump + + setterm -file mydumpfile -dump 4 + +Dump the contents of VC 4 to the file mydumpfile + + setterm -file /dev/tty0 -dump 4 + +Dumps the contents of VC 4 to the current VC. + + setterm -file /dev/tty4 -dump + +Dumps the contents of the current VC to VC 4. + + setterm -file /dev/ttys1 -dump + +Dumps the contents of the current VC to the serial port. +Handy if you are logged on and want to paste a screen full without +having to resort to doing a file transfer. + + setterm -file mydumpfile -append 4 + +Appends to instead of overwriting the dump file. Useful if you +have several screens you wish to concatenate. + + +QUESTION: I've tried clear/reset, like most of unix but it doesn't +work, have I missed something? + +ANSWER: setterm -clear or setterm -reset will solve your missing. For +clear, you can also write a small script (which use the cl: part of +/etc/termcap wrt your TERM), or use bash where ctrl-l will do it for +you. + + +QUESTION: I know there are VC, but where is the setterm stuff? + +ANSWER: It's in the current distribution (i.e. on the images), the +source can be found in virtcons.tar.Z at nic. + + +QUESTION: While using emacs in 80x25 mode, the mode line is constantly +moving around, why? + +ANSWER: This appear to be a bug in the scroll region handling of the +console. I have not tested the new termcap but with the one for 0.12 I +use the following function. + + e(){TERM=vt100; /usr/bin/emacs} + + +QUESTION: When I use make as non root, it doesn't work, why? + +ANSWER: ?????, the message is either (null) setuid ..., or (null) +setgid... I don't know how to fix it. +BTW This problem does not exist with the pmake (make for BSD 4.3 Reno +and BSD 4.4) package. + + +QUESTION: How can I get Linux to boot directly from the harddisk? + +ANSWER: Right now, this can be done via the shoelace stuff or the +bootany package. Quite recently a monitor program has been posted for +Minix, Michael is working on the port to Linux. + + +QUESTION: Sometimes, when I want to remove a directory, I get an error +message, is it a (known) bug? + +ANSWER: No, There is no bug at all, you probaly have another shell +on another VC whose working directory is either the one you try to +remove, either a subdirectory of it. + + +QUESTION: can anyone give me a sample /etc/inittab entry for login +from a pc attached to serial line /dev/ttys2? + +ANSWER: "Humberto speaking :)" +First step up the modem to turn off echo and enable auto answer, I do +this in kermit by connecting to the modem and typing "ate0s0=1" +followed by enter (w/o quotes). Then setup inittab to spawn getty on +the modem +ttys2:console:/etc/agetty -m 1200 ttys2 + +Then it should work. Some modems can be permanently set to disable +echo and set auto answer, see your manual. + +QUESTION: When compiling some code, cc1 complains about some insn +code, what's that? + +ANSWER: An insn is an internal representation that gcc uses when +compiling. The main part of gcc is to take ordinary c (or c++) code, +and compile it, while ding optimizations in insn part, which is +soft/hard independant. Then another part which is hard/Os dependant +takes the insns and translate it in assembly language. The fix is only +to turn off the optimization flag (-O) or download the new gcc release +(1.4) which has been made available at tsx-11 (newgcc.tar.Z and the +ad-hoc libraries newlibc.tar.Z). + + +QUESTION: While compiling some stuff, I'm getting the following +error message: +Undefined symbol ___addsf3 referenced from text segment +as well as ___mulsf3 and __cmpsf2. +These symbols are not in the program or in it's header files. + +ANSWER: These are math helper functions, and you can usually compile +these programs to use the kernel floating point routines by adding +'-m80387' to the compiler switches. If the program does any wierd +fp math (exp(), sin()) it'll die when you run it though. + + +QUESTION: What are the enhancement of the newgcc.tar.Z ? + +ANSWER: There were some bugs in the old port that have been corrected, +moreover this package contains 387 support +there is libm.a (for those with 387) + libsoft.a (for those without, I for example) + libtermcap.a (from tput 1.10) + +The -mstring-insns option is no longer needed nor supported :( [As +an example to recompile (successfully) linux0.12 you have to throw away +this flag in all the Makefile] + +gcc-1.40 has some registers problem, you should had -fcombine-regs +flag while compiling (the linux kernel for example) + +BTW Notice also that include files have changed (stdio.h which is no +more ansi compliant). + + +QUESTION What's about gcc2.0 ? + +ANSWER: It has been ported to linux, but remember that gcc2.0 is an +ALPHA, it is not (yet) stable but it works. Anyway the files are +2lib.tar.Z and 2misc.tar.Z Uncompress and untar 2misc, read the FAQ +enclosed and play with it. You can find these files at tsx-11 in +binaries/compilers/gcc-2.0. In a short while gcc-2.1 will be out, and +will fix many problems. + + +QUESTION: What can gcc-2.0 do for me, that gcc-1.40 cannot? + +ANSWER: Shared libraries: small programs shrink by an average factor +of 2~3, larger program by 50K. It also compiles C++, and so replace +both gcc-1.xx and g++1.xx + + +QUESTION: I've been trying to get Linux to run on my [3/4]86 box. It +can't even boot. Any suggestions? + +ANSWER: The most common error/problem is writing the bootimage to a +low density disk. It fits, but the bootstrap code will only recognize +high density disk. So try to format explicitely disk as high density: +- for 3.5", 'format a: /n:18 /t:80 ' +- for 5.25", 'format a: /n:15 /t:80 ' + + +QUESTION: Does there exist games, languages (other than C), and +anything which make the system more friendly? + +ANSWER: Yes, among other things there are rogue and yatzee; TeX; +Prolog.. but in general, if you want some extra tool port it to Linux +this is also a good beta-testing exercice. + + +QUESTION: Could someone explain how to use rawrite? + +ANSWER: Well, rawrite is a DOS util, which write sequential sector of +a formatted disk/floppy. When a floppy has been rawritten, you can +(under Linux), mount and untar it (only use x, v and f flags). Do not +rawrite compressed files. + +QUESTION: Does emacs handle the arrows-key + +ANSWER: Yes it does, one simple way is to put some elisp code in your +.emacs, this is an except of mine: + +(global-unset-key "\e[") +(setq esc-c-map(make-keymap)) +(fset 'esc-c-prefix esc-c-map) +(define-key global-map "\e[" 'esc-c-prefix) +(define-key global-map "\e[B" 'next-line) +(define-key global-map "\e[A" 'previous-line) +(define-key global-map "\e[C" 'forward-char) +(define-key global-map "\e[D" 'backward-char) + +The keycode was obtained by ^Q followed by the key + + +QUESTION: Whenever I use uemacs 3.1X on a symlink, the symlink does +not exist anymore, why? + +ANSWER: (Tristram Mabbs) Since ue3.10, uemacs uses 'safe save' mode, +writing the file to a temporary and moving it OVER the original. In +the process, this deletes the original. To prevent this just add the +following in your emacs '.rc' file: set $ssave FALSE + + +QUESTION: Uemacs doesn't work anymore with 0.95a, whenever I want to +save a file; what can I do? + +ANSWER: ^S and ^Q are used for flow control. One solution is ^X^W +followed by the filename, or M-X save-file. Another possibility, +if you have download the stty.tar.Z file, is to do stty -IXON +before you first use uemacs (this can be included in your .profile). +And the last is to recompile the Peter Orbaek init-1.2 package. + + +QUESTION: I have an SVGA, but Linux detect an EGAc/EGAm; is it normal? + +ANSWER: (Jim Winstead) This is correct actually. You have an EGA+ card +(SVGA) with a Color/Mono monitor. The only four possibilties are EGAc, +EGAm, *MDA and *CGA (according to the code in +kernel/chr_drv/console.c). +The true test, if Linux detects your video card, is if you press + at the "Press to see SVGA- ..." boot-time message. +If you have a SVGA recognized card, it will ask you to choose a +screen size. If not detected, the default is 80x50 mode. +BTW if you have no SVGA, press the and you are in 80x25 mode. + + ===================8<==========>8================ + diff --git a/Linux-0.95/docs/INFO-SHEET-04.04.92 b/Linux-0.95/docs/INFO-SHEET-04.04.92 new file mode 100644 index 00000000..6e39a2cb --- /dev/null +++ b/Linux-0.95/docs/INFO-SHEET-04.04.92 @@ -0,0 +1,123 @@ +LINUX INFORMATION SHEET +(last updated 13 Jan 1992 (with changes by Linus 4.4.92)) + +1. WHAT IS LINUX 0.95a + LINUX 0.95a is a freely distributable UNIX clone. It implements a +subset of System V and POSIX functionality. LINUX has been written +from scratch, and therefore does not contain any AT&T or MINIX +code--not in the kernel, the compiler, the utilities, or the libraries. +For this reason it can be made available with complete source code by +anonymous FTP. LINUX runs only on 386/486 AT-bus machines; porting to +non-Intel architectures is likely to be difficult, as the kernel makes +extensive use of 386 memory management and task primitives. + + Version 0.95a is still a beta release, but it already provides much +of the functionality of a System V.3 kernel. For example, various +users have been able to port programs such as bison/flex without having +to modify code at all. Another indication of its maturity is that +it is now possible to do LINUX kernel development using LINUX itself +and freely-available programming tools. + +2. LINUX features + - System call compatible with a subset of System V and POSIX + - Full multiprogramming (multiple programs can run at once) + - Memory paging with copy-on-write + - Demand loading of executables + - Page sharing of executables + - Virtual memory: swapping to disk when out of RAM + - POSIX job control + - virtual consoles + - pty's + - some 387-emulation + - ANSI compliant C compiler (gcc) + - A complete set of compiler writing tools + (bison as yacc-replacement, flex as lex replacement) + - The GNU 'Bourne again' shell (bash) (as well as 'ash', 'rc' etc) + - Micro emacs + - most utilities you need for development + (cat, cp, kermit, ls, make, etc.) + - Over 200 library procedures (atoi, fork, malloc, read, stdio, etc.) + - Currently 6 national keyboards: Finnish/US/German/French/British/Danish + - Full source code (in C) for the OS is freely distributable + - Full source code of the tools can be gotten from many anonymous ftp sites + (Almost the entire suite of GNU programs has been ported to Linux.) + - Runs in protected mode on 386 and above + - Support for extended memory up to 16M on 386 and above + - RS-232 serial line support with terminal emulation, kermit, zmodem, etc. + - Supports the real time clock + + +3. HARDWARE REQUIRED + - A 386 or 486 machine with an AT-bus. (EISA will probably work, also, + but you will need an AT-bus hard disk controller.) Both DX and SX + processors will work. + - A hard disk implementing the standard AT hard disk interface -- for + example, an IDE drive. In addition, some SCSI drives are supported + with additional kernel patches. + - A high-density disk drive--either 5.25" (1.2MB) or 3.5" (1.44MB). + - At least 2 megabytes of RAM. (LINUX will boot in 2 Mb. To use gcc + 4 MB is a good idea.) + - Any video card of the following: Hercules,CGA,EGA,VGA + +In addition, LINUX supports + - Up to four serial lines (2 active at a time) + - A real time clock + +4. PARTIAL LIST OF UTILITIES INCLUDED IN OR AVAILABLE FOR LINUX 0.95a + - The MTOOLS package (reading/writing to DOS filesystems) + - The complete GNU filetools (ls, cat, cp, mv, ...) + - The GNU C and C++ compiler with GNU assembler, linker, ar, ... + - bison + - flex + - rcs + - pmake (BSD 4.3 Reno/BSD 4.4 make) + - kermit + - Micro emacs + - less + - mkfs + - fsck + - mount/umount + - TeX, dvips + - and lots more... + +5. LINUX BINARIES + The LINUX binaries and sources are available at several different + anonymous FTP sites. The biggest are: + + nic.funet.fi:/pub/OS/Linux + tsx-11.mit.edu:/pub/linux + + +6. LEGAL STATUS OF LINUX + Although LINUX is supplied with the complete source code, it is +copyrighted software. Unlike MINIX, however, it is available for free, +provided you obey to the rules specified in the LINUX copyright. + + Linux is (C) Linus Torvalds, but the copyright is the GNU copyleft: +get a copy of the copyleft at your nearest ftp-archive.. + +7. NEWS ABOUT LINUX + There are now two newsgroups devoted to linux articles: an older +alt.os.linux and the new comp.os.linux group. The alt-group will be +phased out as the comp-group gets a wider propagation. Additionally, +there are a couple of mailing-lists: linux-activists@niksula.hut.fi is +the original mailing-list, and it now supports sub-threads (notably the +gcc-2 beta-testing list). There is also a linux-standards mailing list +as well as a newsgroup-service for those that can get mail but are +unable to read the newsgroups. For the current status of LINUX, do a +"finger torvalds@kruuna.helsinki.fi". + + +8. FUTURE PLANS + Work is underway on LINUX version 1.0, which will close some of the +gaps in the present implementation. Various people are currently working +on: + - A more complete virtual filesystem layer + - STREAMS + - Interprocess communication + - IEEE POSIX P1003.1 / P1003.2 compatibility + - more complete SCSI support +If you want to help, mail the various activists or post to the newsgroups. + + +-------------------------------------------------------------------------------- \ No newline at end of file diff --git a/Linux-0.95/docs/INSTALL-0.95a b/Linux-0.95/docs/INSTALL-0.95a new file mode 100644 index 00000000..08225c32 --- /dev/null +++ b/Linux-0.95/docs/INSTALL-0.95a @@ -0,0 +1,157 @@ +INSTALL NOTES FOR LINUX v0.95a +Jim Winstead Jr. - March 17, 1992 + +This file contains basic instructions for installing Linux v0.95a. +More detailed instructions are being written by others. Read +alt.os.linux for details on this, and to see preliminary drafts. + +COPYRIGHT + +Linux 0.95a is NOT public domain software, but is copyrighted by Linus +Torvalds (torvalds@cc.helsinki.fi). The copyright terms follow the +GNU Copyleft. See the file COPYING from any GNU software package for +the finer points. Note that the unistd library functions and all +library functions written by Linus Torvalds are exempt from this +copyright, and you may use them as you wish. + +INSTALLATION + +1) First, and absolutely the most important step, MAKE BACKUPS OF YOUR + SYSTEM! This system won't do anything nearly as nasty as coredump all + over your harddrive (see 386BSD v0.0), but it is quite easy to + accidently screw something up while installing. + +2) Test out the Linux v0.95a boot disk with the Linux v0.95a root + disk. If you are unable to get the boot disk to work properly on + your system, try posting to alt.os.linux, or contacting Linus. + + Notice that Linux (as of v0.95) contains an init/getty/login suite, + and this will start up 'login' on the first four virtual consoles, + accessed by Left-Alt-F[1234]. If you experience problems on one + virtual console, it should be possible to switch to another one. + + (There is a good chance the backspace key will not work with + /bin/sh on your first virtual console, as this how it often behaves + on my machine. I've noticed that it usually works in the other + virtual consoles, however.) + +3) Run the 'fdisk' program on the root floppy. This will tell you how + each of your harddrives is partitioned. Note that the names of the + hard drive partitions has changed from v0.12, and 'fdisk' now + properly reports the new device names (unlike the fdisk with v0.95). + + If 'fdisk' tells you about any partitions at all, Linux can + successfully read at least part of your harddisk, and you will most + likely be able to install Linux on your harddrive. + + If you have used previous versions of Linux, you will notice that + 'fdisk' now recognizes extended partitions. Support for this in + the kernel, however, is largely untested. If you're feeling brave, + go ahead and try, and report any problems to Linus. + +4) Make sure you have a free (preferably primary) partition on your + hard drive. If you want to repartition your harddrive, you can use + the pfdisk program on the root floppy. See pfdisk.man in the + /INSTALL directory for more details on using this program. (NOTE: + you will need to know your hard drives disk geometry to use pfdisk. + You can find this out by examining your CMOS setup on most computers.) + +5) If you have used pfdisk to change your partition table, be sure to + reboot Linux now, so the new partition table will be recognized by + Linux. + +6) Use 'fdisk' again to check the partitions on your hard drive, and + use 'mkfs' to make a Linux (minix) filesystem on the partition you + want to be using for Linux. The proper command is "mkfs + /dev/hdX nnn" where X is the partition (i.e. a1, a2, b3, etc.) and + nnn is the size in blocks (kilobytes) of the partition as reported + by fdisk. You should be able to use the size of the partitions to + tell them apart. + +7) Mount the new filesystem. This can be done by using "mount + /dev/hdX /mnt", which will mount the partition into the directory + /mnt. + +8) Run the script in /INSTALL called 'mktree'. This will create a + bare directory tree built down from the specified directory. So, + for a standard installation, you would use "mktree /mnt", which + would build the bare directory tree starting from /mnt. + +9) Run the script in /INSTALL called 'mkdev'. This will create the + standard Linux devices in the directory 'dev' in the specified + directory. For a standard installtion, this would mean typing + 'mkdev /mnt' to create the devices in /mnt/dev. + + NOTE: This step is really optional, since the 'install' script + (next step) will do this if it sees you haven't. + +10) Run the script in /INSTALL called 'install'. This will copy over + the binary programs from the root disk to the directory tree on + the specified directory. This means typing 'install /mnt' for a + standard installation. + + NOTE: (for those upgrading from previous versions of Linux) + + The 'install' script uses the +interactive switch for copying + files from /etc, which means you can tell it whether or not to + overwrite any of these files. 'install' will also go through + your /usr/bin and /bin directories and ask you if it should + remove any incorrectly placed files. (Such as /bin/update and + /bin/init, which have both been moved to /etc.) + +11) You should now have a complete (but very basic) root filesystem on + your harddrive. To be able to boot from floppy with this as your + root filesystem, you will have to edit the boot diskette. This is + done by modifying the word at offset 508 (decimal) with a program + such as Norton's Disk Editor, or use pboot.exe (available where + you got this file, the boot disk and the root disk, hopefully.) + + This word is in 386-order (that is, least-significant byte first), + which means it should look like one of the following: + + LSB MSB - device + -------------------------- + 01 03 - /dev/hda1 LSB = Least-Significant Byte + 02 03 - /dev/hda2 MSB = Most-Significant Byte + 03 03 - /dev/hda3 + 04 03 - /dev/hda4 + + 41 03 - /dev/hdb1 + 42 03 - /dev/hdb2 + 43 03 - /dev/hdb3 + 44 03 - /dev/hdb4 + + The numbers are in hex, and if you're editing the boot diskette by + hand, these two bytes should initially be 00 00 (and are followed + by two non-zero bytes). + + Note that pboot.exe predates Linux 0.95a, so some of the + information it presents is inaccurate (it refers to the old hd* + naming scheme). The codes to use are as above, but with the most- + significant byte first. (So /dev/hda1 = 0301, /dev/hda2 = 0302, + etc.) + +12) You should now be able to boot from this diskette and it will use + your new Linux partition as the root partition. You'll notice, + however, that you can't do a whole lot with just the programs on + the root diskette. You'll need to get further packages from + whereever you got the root and boot diskettes, and read these from + a floppy using tar and compress. (Simple instructions: Download + the file to DOS, use rawrite to write the tar file to diskette. + Use 'tar zxvf /dev/' to read the file from floppy, where + is the appropriate floppy device. (PS0 is a 1.44 meg + 3.5" as A:, PS1 is a 1.44 meg as B:, at0 is a 1.2 meg as A:, at1 + is a 1.2 meg as B:.) + +13) Before you ever reboot your machine when it's running Linux, you + should run 'sync'. This flushes Linux's disk buffers, making sure + everything has been written to disk. Failing to do this could + result in badly corrupted filesystems. + +---------------------------------------------------------------------------- + +These instructions are not the best, but should be enough to get you +going. If you have more questions, either post on alt.os.linux, or +send mail to me (jwinstea@jarthur.Claremont.EDU), or to Linus +(torvalds@cc.helsinki.fi). Remember, the only stupid questions are +the ones that you don't ask. diff --git a/Linux-0.95/docs/README-0.95c+ b/Linux-0.95/docs/README-0.95c+ new file mode 100644 index 00000000..7f941fe8 --- /dev/null +++ b/Linux-0.95/docs/README-0.95c+ @@ -0,0 +1,59 @@ +This is release 0.95c+ of the linux kernel - it contains some +enhancements and bugfixes to the 0.95a kernel, as well as some minor +fixes relative to the last alpha-patch (0.95c). The release is +available as + +- binary (bootimage-0.95c+.Z) +- full source (linux-0.95c+.tar.Z) +- patches rel. to 0.95c (diff-0.95c.c+.Z) +- patches rel. to 0.95a (diff-0.95a.c+.Z) + +NOTE TO PATCHERS!! Before patching, do this: + - make an empty include-file linux/include/checkpoint.h + - rename linux/kernel/math/math_emulate.c as just emulate.c +That is, from the linux source directory do: + + $ > include/checkpoint.h + $ mv kernel/math/math_emulate.c kernel/math/emulate.c + +Also note that patching from the 0.95a version is probably not worth it +as it's easier to get the complete new sources. + +Although I'm making binaries and the full source available, this isn't +really a major release: there is no new rootdisk, and this is more "my +current kernel" and not really tested (I put in the last changes 5 +minutes before packing all this up). + +The reason I'm making this available is that with the advent of gcc-2.1 +and the VFS-library the old kernel doesn't really do everything the new +libraries want: the readdir system call is needed to get things working. +The default compiler after this release is considered to be gcc-2.0 or +higher (although 1.40 still works - you don't /have/ to change). People +who are unable or unwilling to patch a new kernel shouldn't be unable to +run the new binaries. + +This kernel should be totally backwards compatible, so no binaries +should break. I resisted adding the changed mount() system call into +this release: the next major release will have a third parameter for +mount() - the filesystem type name (ie mount /dev/xxx /mnt minix). + +Fixes relative to 0.95c: + +- corrected two minor bugs in readdir() (thanks to R Card) + +- lp-patches are in. I've edited them a bit, and will probably do some + more editing in the future, but they seem to work fine. + +- 8-bit ISO latin output to the console (ie part of Johan Myreens + general latin-1 patches: the keyboard patches aren't there) + +- other minor bug-fixes (thanks to HH Bergman for noticing the + timer-table bug) + +Things I haven't had time to look into yet: + +- select still has some problems +- reports that VC-output sometimes isdiscarded (never seen it myself) +- probably other things I've simply forgot... + + Linus diff --git a/Linux-0.95/docs/RELNOTES-0.95 b/Linux-0.95/docs/RELNOTES-0.95 new file mode 100644 index 00000000..909b89ef --- /dev/null +++ b/Linux-0.95/docs/RELNOTES-0.95 @@ -0,0 +1,265 @@ + + + RELEASE NOTES FOR LINUX v0.95 + Linus Torvalds, March 7, 1992 + + +This is file mostly contains info on changed features of Linux, and +using old versions as a help-reference might be a good idea. + + + COPYRIGHT + +Linux-0.95 is NOT public domain software, but is copyrighted by me. The +copyright conditions are the same as those imposed by the GNU copyleft: +get a copy of the GNU copyleft at any major ftp-site (if it carries +linux, it probably carries a lot of GNU software anyway, and they all +contain the copyright). + +The copyleft is pretty detailed, but it mostly just means that you may +freely copy linux for your own use, and redistribute all/parts of it, as +long as you make source available (not necessarily in the same +distribution, but you make it clear how people can get it for nothing +more than copying costs). Any changes you make that you distribute will +also automatically fall under the GNU copyleft. + +NOTE! The linux unistd library-functions (the low-level interface to +linux: system calls etc) are excempt from the copyright - you may use +them as you wish, and using those in your binary files won't mean that +your files are automatically under the GNU copyleft. This concerns +/only/ the unistd-library and those (few) other library functions I have +written: most of the rest of the library has it's own copyrights (or is +public domain). See the library sources for details of those. + + + INSTALLATION + +This is a SHORT install-note. The installation is very similar to 0.11 +and 0.12, so you should read INSTALL-0.11 too. There are a couple of +programs you will need to install linux: something that writes disk +images (rawrite.exe or NU or...) and something that can create harddisk +partitions (fdisk under xenix or older versions of dos, edpart.exe or +something like that). + +NOTE! Repartitioning your harddisk will destroy all data on it (well, +not exactly, but if you know enough to get back the data you probably +didn't need this warning). So be careful. + +READ THIS THROUGH, THEN READ INSTALL-0.11, AND IF YOU ARE SURE YOU KNOW +WHAT YOU ARE DOING, CONTINUE. OTHERWISE, PANIC. OR WRITE ME FOR +EXPLANATIONS. OR DO ANYTHING BUT INSTALL LINUX - IT'S VERY SIMPLE, BUT +IF YOU DON'T KNOW WHAT YOU ARE DOING YOU'LL PROBABLY BE SORRY. I'D +RATHER ANSWER A FEW UNNECESSARY MAILS THAN GET MAIL SAYING "YOU KILLED +MY HARDDISK, BASTARD. I'M GOING TO FIND YOU, AND YOU'LL BE SORRY WHEN I +DO". + +Minumum files needed: + + RELNOTES-0.95 (this file) + INSTALL-0.11 (+ any other docs you might find: the FAQ etc) + bootimage-0.96.Z + rootimage-0.95.Z + rootimage-0.12.Z (for tar+compress) + rawrite.exe + some disk partitioner + +1) back up everything you have on your harddisk - linux-0.95 is still in + beta and might do weird things. The only thing I guarantee is that + it has worked fine on /my/ machine - for all I know it might eat your + harddisk and spit it out in small pieces on any other hardware. + +2) Test out the linux boot-disk with the root file system. If it + doesn't work, check the hardware requirements, and mail me if you + still think it should work. I might not be able to help you, but + your bug-report would still be appreciated. + + Linux-0.95 now has an init/login: there should be 4 logins started on + the first 4 virtual consoles. Log in as root (no password), and test + it out. Change to the other logins by pressing left-alt + FN[1-4]. + Note that booting up with a floppy as root is S..L..O..W.. - the + floppy driver has been optimized for sequential access (backups etc), + and trashes somewhat with demand-loading. + + Test that linux can read your harddisk at least partly: run the fdisk + program on the root-disk, and see if it barfs. If it tells you about + any partitions at all, linux can successfully read at least part of + your harddisk. + + NOTE! Harddisk device names and numbers have changed between versions + 0.12 and 0.95: the new numbering system was needed for the extended + partitions, and a new naming scheme was in order so that people + wouldn't cunfuse the old devices with the new ones. + + The new harddisk device names are: /dev/hd followed by an 'a' for the + first drive, or a 'b' for the second one. After that comes the + partition number, 1-4 for the primary partitions, 5- for possible + extended partitions. No number means the complete disk. Like this: + + /dev/hda the whole first harddisk (old: /dev/hd0) + /dev/hdb3 partition nr 3 on the second disk (old: /dev/hd8) + +3) Make sure that you have a free /primary/ partition. There can be 4 + primary partitions per drive: newer DOS fdisks seem to be able to + create only 2 (one primary and one extended). In that case use some + other partitioning software: edpart.exe etc. Linux fdisk currently + only tells you the partition info - it doesn't write to the disk. + + Remember to check how big your partition was, as that can be used to + tell which device Linux thinks it is. + + NOTE! Linux-0.95 /might/ recognize extended partitions: but the code + for this is utterly untested, as I don't have any of those. Do NOT + use the extended partitions unless you can verify that they are + indeed correctly set up - if my routines are wrong, writing to the + extended partitions might just overwrite some other partition + instead. Not nice. + +4) Boot up linux again, fdisk to make sure you now have the new + partition, and use mkfs to make a filesystem on one of the partitions + fdisk reports. Write "mkfs -c /dev/hdX nnn" where X is the device + number reported by linux fdisk, and nnn is the size - also reported + by fdisk. nnn is the size in /blocks/, ie kilobytes. You should be + able to use the size info to determine which partition is represented + by which device name. + +5) Mount the new disk partition: "mount /dev/hdX /mnt". Copy over the + root filesystem to the harddisk, eg like this: + + # for i in bin dev etc usr tmp + # do + # cp +recursive /$i /mnt + # done + + You caanot use just "cp +recursive / /mnt", as that will result in a + loop. + +6) Sync the filesystem after you have played around enough, and reboot. + + # sync + # lo + + (none) login: sync + + ctrl-alt-del + + THIS IS IMPORTANT! NEVER EVER FORGET TO SYNC BEFORE KILLING THE MACHINE. + +7) Change the bootdisk to understand which partition it should use as a + root filesystem. See INSTALL-0.11: it's still the word at offset + 508 into the image. You should be up and running. + + +8) When you've successfully started up with your harddisk as root, you + can mount the older rootimage (rootimage-0.12) from a floppy, and + copy over any files you find there that weren't on the newer + root-image. + + Mounting a floppy is easy: make the directory /floppy, and write: + + # mount /dev/PS0 /floppy (if you have a 3.5" drive) + + or + + # mount /dev/at0 /floppy (for 5.25" floppies) + + After that the files can be copied to your harddisk, eg: + + # cp /floppy/usr/bin/compress /usr/bin + # ln -s /usr/bin/compress /usr/bin/compress + # cp /floppy/usr/bin/tar.Z /usr/bin + # uncompress /usr/bin/tar.Z + +That's it. Now go back and read the INSTALL-0.11, until you are sure you +know what you are doing. + + + New features of 0.95, in order of appearance + (ie in the order you see them) + + Init/login + +Yeah, thanks to poe (Peter Orbaeck (sp?)), linux now boots up like a +real unix with a login-prompt. Login as root (no passwd), and change +your /etc/passwd to your hearts delight (and add other logins in +/etc/inittab etc). + + Bash is even bigger + +It's really a bummer to boot up from floppies: bash takes a long time to +load. Bash is also now so big that I couldn't fit compress and tar onto +the root-floppy: You'll probably want the old rootimage-0.12 just in +order to get tar+compress onto your harddisk. If anybody has pointers +to a simple shell that is freely distributable, it might be a good idea +to use that for the root-diskette. + +Especially with a small buffer-cache, things aren't fun. Don't worry: +linux runs much better on a harddisk. + + Virtual consoles on any (?) hardware. + +You can select one of several consoles by pressing the left alt-key and +a function key at the same time. Linux should report the number of +virtual consoles available upon bootup. /dev/tty0 is now "the current" +screen, /dev/tty1 is the main console, and /dev/tty2-8 can exist +depending on your text-mode or card. + +The virtual consoles also have some new screen-handling commands: they +confirm even better to vt200 control codes than 0.11. Special graphic +characters etc: you can well use them as terminals to VMS (although +that's a shameful waste of resources), and the PF1-4 keys work somewhat +in the application-key mode. + + Symbolic links. + +0.95 now allows symlinks to point to other symlinks etc (the maximum +depth is a rather arbitrary 5 links). 0.12 didn't like more than one +level of indirection. + + Virtual memory. + +VM under 0.95 should be better than under 0.12: no more lockups (as far +as I have seen), and you can now swap to the filesystem as well as to a +special partition. There are two programs to handle this: mkswap to set +up a swap-file/partition and swapon to start up swapping. + +mkswap needs either a partition or a file that already exists to make a +swap-area. To make a swap-file, do this: + + # dd bs=1024 count=NN if=/dev/hda of=swapfile + # mkswap swapfile NN + +The first command just makes a file that is NN blocks long (initializing +it from /dev/hda, but that could be anything). The second command then +writes the necessary setup-info into the file. To start swapping, write + + # swapon swapfile + +NOTE! 'dd' isn't on the rootdisk: you have to install some things onto +the harddisk before you can get up and running. + +NOTE2! When linux runs totally out of virtual memory, things slow down +dramatically. It tries to keep on running as long as it can, but at +least it shouldn't lock up any more. ^C should work, although you might +have to wait a while for it.. + + Faster floppies + +Ok, you don't notice this much when booting up from a floppy: bash has +grown, so it takes longer to load, and the optimizations work mostly +with sequential accesses. When you start un-taring floppies to get the +programs onto your harddisk, you'll notice that it's much faster now. +That should be about the only use for floppies under a unix: nobody in +their right mind uses floppies as filesystems. + + Better FS-independence + +Hopefully you'll never even notice this, but the filesystem has been +partly rewritten to make it less minix-fs-specific. I haven't +implemented all the VFS-patches I got, so it's still not ready, but it's +getting there, slowly. + + And that's it, I think. + +Happy hacking. + + Linus (torvalds@kruuna.helsinki.fi) diff --git a/Linux-0.95/docs/RELNOTES-0.95a b/Linux-0.95/docs/RELNOTES-0.95a new file mode 100644 index 00000000..e8dd4723 --- /dev/null +++ b/Linux-0.95/docs/RELNOTES-0.95a @@ -0,0 +1,163 @@ + + RELEASE NOTES FOR LINUX v0.95a + Linus Torvalds, March 17, 1992 + + +This is file mostly contains info on changed features of Linux, and +using old versions as a help-reference might be a good idea. + + COPYRIGHT + +Linux-0.95a is NOT public domain software, but is copyrighted by me. The +copyright conditions are the same as those imposed by the GNU copyleft: +get a copy of the GNU copyleft at any major ftp-site (if it carries +linux, it probably carries a lot of GNU software anyway, and they all +contain the copyright). + +The copyleft is pretty detailed, but it mostly just means that you may +freely copy linux for your own use, and redistribute all/parts of it, as +long as you make source available (not necessarily in the same +distribution, but you make it clear how people can get it for nothing +more than copying costs). Any changes you make that you distribute will +also automatically fall under the GNU copyleft. + +NOTE! The linux unistd library-functions (the low-level interface to +linux: system calls etc) are excempt from the copyright - you may use +them as you wish, and using those in your binary files won't mean that +your files are automatically under the GNU copyleft. This concerns +/only/ the unistd-library and those (few) other library functions I have +written: most of the rest of the library has it's own copyrights (or is +public domain). See the library sources for details of those. + + + NEW FEATURES OF 0.95a + + +0.95a is mainly a bug-fix release: it didn't even get it's own version +number. Plain 0.95 fixed a lot of bugs in 0.12, but also introduced +totally new bugs: 0.95a tries to correct these. The bugs corrected +(knock wood) are: + +- floppy and harddisk drivers should now once more work with most + hardware: I'd be interested in reports of "unexpected HD interrupt" + and "reset-floppy called" with the new kernel. + +- A rather serious tty-bug corrected: this one messed up the screen + under 0.95, and switched characters over the serial lines. Under + extreme circumstances it could even crash the machine. + +- ptrace had a bug: hopefully it works now. + +- The extended partitions didn't work under 0.95, although most of the + code was there. Please somebody tell me it works under 0.95a. + +- the 0.95 fdisk was broken: a new one with the new root-floppy should + clear up the confusion. + +- select() and the sleep-wakeup code had fundamental (but relatively + benign) problems under 0.95 (and all earlier versions). The sleeping + code is totally redesigned, and select should work better even under + load. + +One actual new feature, not just a bug-fix: + +- ser3-4 support is there, although I've been unable to test it (as I + haven't got more than ser2). NOTE! Due to AT hardware limitations, + ser1 cannot be active at the same time as ser3, and likewise ser2 and + ser4 are mutually exclusive. The interrupt-handlers should have no + problems with shared interrupts, but the actual hardware probably has, + so the kernel disables interrupts from one serial line when the other + one is opened. + +- faster default keyrepeat rate: this is going to need some getting used + to, but is extremely practical especially with bigger screen sizes. + +- VGA cards that aren't recognized at bootup are put into the 80x50 + character mode if was pressed when asking about SVGA modes. + + + NEW FEATURES OF 0.95 + + Init/login + +Yeah, thanks to poe (Peter Orbaeck (sp?)), linux now boots up like a +real unix with a login-prompt. Login as root (no passwd), and change +your /etc/passwd to your hearts delight (and add other logins in +/etc/inittab etc). + + Virtual consoles on any (?) hardware. + +You can select one of several consoles by pressing the left alt-key and +a function key at the same time. Linux should report the number of +virtual consoles available upon bootup. /dev/tty0 is now "the current" +screen, /dev/tty1 is the main console, and /dev/tty2-8 can exist +depending on your text-mode or card. + +The virtual consoles also have some new screen-handling commands: they +confirm even better to vt200 control codes than 0.11. Special graphic +characters etc: you can well use them as terminals to VMS (although +that's a shameful waste of resources), and the PF1-4 keys work somewhat +in the application-key mode. + + Extended vt200 emulation + +0.95 contains code to handle a vt200 application keymap mode: the cursor +keys send slightly different codes when in application mode, and the +numeric keyboard tries to emulate the vt200 application keys. This +probably isn't complete yet. + + Symbolic links. + +0.95 now allows symlinks to point to other symlinks etc (the maximum +depth is a rather arbitrary 5 links). 0.12 didn't like more than one +level of indirection. + + Virtual memory. + +VM under 0.95 should be better than under 0.12: no more lockups (as far +as I have seen), and you can now swap to the filesystem as well as to a +special partition. There are two programs to handle this: mkswap to set +up a swap-file/partition and swapon to start up swapping. + +mkswap needs either a partition or a file that already exists to make a +swap-area. To make a swap-file, do this: + + # dd bs=1024 count=NN if=/dev/hda of=swapfile + # mkswap swapfile NN + +The first command just makes a file that is NN blocks long (initializing +it from /dev/hda, but that could be anything). The second command then +writes the necessary setup-info into the file. To start swapping, write + + # swapon swapfile + +NOTE! 'dd' isn't on the rootdisk: you have to install some things onto +the harddisk before you can get up and running. + +NOTE2! When linux runs totally out of virtual memory, things slow down +dramatically. It tries to keep on running as long as it can, but at +least it shouldn't lock up any more. ^C should work, although you might +have to wait a while for it.. + + Faster floppies + +Ok, you don't notice this much when booting up from a floppy: bash has +grown, so it takes longer to load, and the optimizations work mostly +with sequential accesses. When you start un-taring floppies to get the +programs onto your harddisk, you'll notice that it's much faster now. +That should be about the only use for floppies under a unix: nobody in +their right mind uses floppies as filesystems. + + Better FS-independence + +Hopefully you'll never even notice this, but the filesystem has been +partly rewritten to make it less minix-fs-specific. I haven't +implemented all the VFS-patches I got, so it's still not ready, but it's +getting there, slowly. + + + And that's it, I think. + +Happy hacking. + + Linus (torvalds@kruuna.helsinki.fi) \ No newline at end of file diff --git a/Linux-0.95/docs/RELNOTES-0.95c+ b/Linux-0.95/docs/RELNOTES-0.95c+ new file mode 100644 index 00000000..7f941fe8 --- /dev/null +++ b/Linux-0.95/docs/RELNOTES-0.95c+ @@ -0,0 +1,59 @@ +This is release 0.95c+ of the linux kernel - it contains some +enhancements and bugfixes to the 0.95a kernel, as well as some minor +fixes relative to the last alpha-patch (0.95c). The release is +available as + +- binary (bootimage-0.95c+.Z) +- full source (linux-0.95c+.tar.Z) +- patches rel. to 0.95c (diff-0.95c.c+.Z) +- patches rel. to 0.95a (diff-0.95a.c+.Z) + +NOTE TO PATCHERS!! Before patching, do this: + - make an empty include-file linux/include/checkpoint.h + - rename linux/kernel/math/math_emulate.c as just emulate.c +That is, from the linux source directory do: + + $ > include/checkpoint.h + $ mv kernel/math/math_emulate.c kernel/math/emulate.c + +Also note that patching from the 0.95a version is probably not worth it +as it's easier to get the complete new sources. + +Although I'm making binaries and the full source available, this isn't +really a major release: there is no new rootdisk, and this is more "my +current kernel" and not really tested (I put in the last changes 5 +minutes before packing all this up). + +The reason I'm making this available is that with the advent of gcc-2.1 +and the VFS-library the old kernel doesn't really do everything the new +libraries want: the readdir system call is needed to get things working. +The default compiler after this release is considered to be gcc-2.0 or +higher (although 1.40 still works - you don't /have/ to change). People +who are unable or unwilling to patch a new kernel shouldn't be unable to +run the new binaries. + +This kernel should be totally backwards compatible, so no binaries +should break. I resisted adding the changed mount() system call into +this release: the next major release will have a third parameter for +mount() - the filesystem type name (ie mount /dev/xxx /mnt minix). + +Fixes relative to 0.95c: + +- corrected two minor bugs in readdir() (thanks to R Card) + +- lp-patches are in. I've edited them a bit, and will probably do some + more editing in the future, but they seem to work fine. + +- 8-bit ISO latin output to the console (ie part of Johan Myreens + general latin-1 patches: the keyboard patches aren't there) + +- other minor bug-fixes (thanks to HH Bergman for noticing the + timer-table bug) + +Things I haven't had time to look into yet: + +- select still has some problems +- reports that VC-output sometimes isdiscarded (never seen it myself) +- probably other things I've simply forgot... + + Linus diff --git a/Linux-0.95/docs/gcc+kernel.notes.Z b/Linux-0.95/docs/gcc+kernel.notes.Z new file mode 100644 index 00000000..55ceecfb Binary files /dev/null and b/Linux-0.95/docs/gcc+kernel.notes.Z differ diff --git a/Linux-0.95/docs/install.notes.Z b/Linux-0.95/docs/install.notes.Z new file mode 100644 index 00000000..92cea863 Binary files /dev/null and b/Linux-0.95/docs/install.notes.Z differ diff --git a/Linux-0.95/docs/kernel.notes.Z b/Linux-0.95/docs/kernel.notes.Z new file mode 100644 index 00000000..6eddfd25 Binary files /dev/null and b/Linux-0.95/docs/kernel.notes.Z differ diff --git a/Linux-0.95/docs/linux-fs-standard b/Linux-0.95/docs/linux-fs-standard new file mode 100644 index 00000000..736c30f6 --- /dev/null +++ b/Linux-0.95/docs/linux-fs-standard @@ -0,0 +1,279 @@ +From: abc@banjo.concert.net (Alan B Clegg) +Subject: Linux File System Document Revision 1.0 +Date: 9 Mar 92 14:33:45 GMT + +Before I get a flamefull response, let me tell everyone that this document has +been through several revisions, and is currently at a point that has pleased +most people. Please note that it is a *GUIDELINE* and is not *REQUIRED*, but +if most people follow the guidelines, we all get along a lot better. + +If you have comments/questions about this document, and you are not on the +linux-standards mailing list, I would ask that you join the list. The request +address is: linux-standards-request@banjo.concert.net. Please try to keep +debate off the news group, and on the mailing list. + +For those of you on the linux-standards list, the verticle bars in column one +represent the only changes from draft 2. + +==== SNIP HERE ==== + +The following is being submitted by Alan Clegg [abc@concert.net] on behalf +of the Linux-Standards list as the standard for directory file structure +under Linux. + +Revision 1.0 + +Complete implementation of this file structure is completely voluntary, +and will not be enforced, but will be recommended. This specification +is released as guidelines for people porting and writing software for +the Linux Operating System to allow easy software installation, upgrade, and +tailoring on already installed systems. + +Root Directory: + + Files: + {none defined by spec} + + Directories: + bin dev etc home lib mnt usr + + Rationale: + The root directory should not be cluttered with files or + directories, and should contain no user programs. + +/bin Directory: + + Files: + sh init mount umount dd cat ls fsck {and as needed} + + Directories: + {none defined by spec} + + Rationale: + The /bin directory should contain programs that are vital + to the restoration of other file systems in the case of + a corrupting crash. No executable in /bin should require + any other file system to be mounted to execute correctly. + +/dev Directory: + + Files: + {device files} + + Directories: + {none define by spec} + + Rationale: + Standard UNIX device files. This directory should contain + device entries for all devices that are supported in the + standard kernel, even if the hardware device does not exist + on the system. + +/etc Directory: + + Files: + mtab passwd rc ttytab {and as needed} + + Directories: + {none defined by spec} + + Rationale: + Standard location of files required during system boot. Files + in this directory are usually system specific. Most will +| require human intervention during system upgrade. /etc will +| also contain administrative binaries that should not be in +| the normal users PATH. + +/home Directory: + + Files: + NONE + + Directories: + {one per user excepting root} + + Rationale: + Standard location of users home directories. Will most likely + be a mounted file system once the system is up. root's home + directory should be /. + +/lib Directory: + + Files: + {libraries required for system initialization} + + Directories: + {none defined by spec} + + Rationale: + To keep the size of the root partition small (if separate from + /usr), the files in this directory should only be ones required + by files in the root partition. + +/mnt Directory: + + Files: + NONE + + Directories: + NONE + + Rationale: + Standard mount point for external (transient) file systems. + Must be available for sub-system installation. Should remain + as an empty directory. + +/tmp Directory: + + Files: + NONE + + Directories: + NONE + + Rationale: + Temporary file space available for general program use. May + become a mounted partition upon system boot. + +/usr Directory: + + Files: + {none defined by spec} + + Directories: + adm bin spool local lib etc man include src tmp + + Rationale: + /usr is the mount point for the second major (after root) + hierarchy of file structure and is discussed in the next + section. + +/usr/adm Directory: + + Files: + {none defined in spec} + + Directories: + {none defined in spec} + + Rationale: + Location of log files and accounting information. + +/usr/bin Directory: + + Files: + {all executable files from standard distribution not contined + in /bin} + + Directories: + {none defined in spec} + + Rationale: + contains 'drop-in' executables that are considered to be + standard to the UNIX system. These files should NOT be + Linux specific, but should have the same function as their + UNIX equivalents. + +/usr/etc Directory: + + Files: + {none defined in spec} + + Directories: + {none defined in spec} + + Rationale: + contains configuration files for any files in /usr/bin. helps + to keep /etc clean and small. + +/usr/spool Directory: + + Files: + {none defined in spec} + + Directories: + uucp mail + + Rationale: + containes spool files for mail, printing, uucp transfer, etc. + May be a mount point for another volume. + +/usr/local Directory: + + Files: + NONE + + Directories: + bin lib etc man src + + Rationale: + contains files local to the specific system. will not be + modified by upgrade process. + +/usr/lib Directory: + + Files: + libc.a crt0.s {and as needed} + + Directories: + {none defined in spec} + + Rationale: + location for library files required for multi-user system + operation. This is the directory where program libraries +| should reside. /usr/lib will also contain binaries required +| to support programs residing in /usr/bin. + +/usr/man Directory: + + Files: + NONE + + Directories: + man1 man2 man3 man4 man5 man6 man7 man8 + + Rationale: + Contains manual pages for programs that are standard with + Linux. + +/usr/include Directory: + + Files: + {programmers include files} + + Directories: + {as needed} + + Rationale: + Standard place for system include files. + +/usr/src Directory: + + Files: + NONE + + Directories: + bin lib linux usr.bin usr.lib + + Rationale: + Contains source code for all applications in the release. + /usr/src/linux contains directories required for kernel builds. + +/usr/tmp Directory: + + Files: + NONE + + + Directories: + NONE + + Rationale: + Used as additional scratch space for programs. If /tmp is + a mounted file system, /usr/tmp may be a symbolic link to + /tmp. + +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + diff --git a/Linux-0.95/docs/linux-standards/000-README b/Linux-0.95/docs/linux-standards/000-README new file mode 100644 index 00000000..9a61c286 --- /dev/null +++ b/Linux-0.95/docs/linux-standards/000-README @@ -0,0 +1,21 @@ +alt.os.linux #309 [1] +From: abc@banjo.concert.net (Alan B Clegg) +[1] Announcing: linux-standards mailing list. +Organization: Concert Network -- Internet Operations Group +Date: Tue Jan 28 10:42:51 EST 1992 + +I am happy to announce the creation of the Linux Standards (linux-standards) +mailing list. The list is chartered as follows: + +linux-standards: Discussion of distribution and directory standards for + the Linux Operating System, including directory structure, + file location, and release disk format. + +Requests to be added to the mailing list should be sent to: + linux-standards-request@banjo.concert.net + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + diff --git a/Linux-0.95/docs/linux-standards/File_System_Standard b/Linux-0.95/docs/linux-standards/File_System_Standard new file mode 100644 index 00000000..366a5b11 --- /dev/null +++ b/Linux-0.95/docs/linux-standards/File_System_Standard @@ -0,0 +1,254 @@ +The following is being submitted by Alan Clegg [abc@concert.net] on behalf of +the linux-standards group as the recommended standard for directory file +structure under Linux. + +Complete implementation of this file structure is completely voluntary, +and will not be enforced, but will be recommended. This specification +is released as guidelines for people porting and writing software for +the Linux Operating System to allow easy software installation, upgrade, and +tailoring on already installed systems. + +Root Directory: + + Files: + {none defined by spec} + + Directories: + bin dev etc home lib mnt usr + + Rationale: + The root directory should not be cluttered with files or + directories, and should contain no user programs. + +/bin Directory: + + Files: + sh init mount umount dd cat ls fsck mkfs {and as needed} + + Directories: + {none defined by spec} + + Rationale: + The /bin directory should contain programs that are vital + to the restoration of other file systems in the case of + a corrupting crash. No executable in /bin should require + any other file system to be mounted to execute correctly. + +/dev Directory: + + Files: + {device files} + + Directories: + {none define by spec} + + Rationale: + Standard UNIX device files. This directory should contain + device entries for all devices that are supported in the + standard kernel, even if the hardware device does not exist + on the system. Note that the distribution will have all + device files, but they may be removed by the user upon + system installation. + + +/etc Directory: + + Files: + mtab passwd rc ttytab {and as needed} + + Directories: + {none defined by spec} + + Rationale: + Standard location of files required during system boot. Files + in this directory are usually system specific. Most will + require human intervention during system upgrade. + +/home Directory: + + Files: + NONE + + Directories: + {one per user excepting root} + + Rationale: + Standard location of users home directories. Will most likely + be a mounted file system once the system is up. root's home + directory should be /. + +/lib Directory: + + Files: + {libraries required for system initialization} + + Directories: + {none defined by spec} + + Rationale: + To keep the size of the root partition small (if separate from + /usr), the files in this directory should only be ones required + by files in the root partition. + +/mnt Directory: + + Files: + NONE + + Directories: + NONE + + Rationale: + Standard mount point for external (transient) file systems. + Must be available for sub-system installation. Should remain + as an empty directory. + +/tmp Directory: + + Files: + NONE + + Directories: + NONE + + Rationale: + Temporary file space available for general program use. May + become a mounted partition upon system boot. + +/usr Directory: + + Files: + {none defined by spec} + + Directories: + adm bin spool local lib etc man include src tmp + + Rationale: + /usr is the mount point for the second major (after root) + hierarchy of file structure and is discussed in the next + section. + +/usr/adm Directory: + + Files: + {none defined in spec} + + Directories: + {none defined in spec} + + Rationale: + Location of log files and accounting information. + +/usr/bin Directory: + + Files: + {all executable files from standard distribution not contined + in /bin} + + Directories: + {none defined in spec} + + Rationale: + contains 'drop-in' executables that are considered to be + standard to the UNIX system. These files should NOT be + Linux specific, but should have the same function as their + UNIX equivalents. + +/usr/etc Directory: + + Files: + {none defined in spec} + + Directories: + {none defined in spec} + + Rationale: + contains configuration files for any files in /usr/bin. helps + to keep /etc clean and small. + +/usr/spool Directory: + + Files: + {none defined in spec} + + Directories: + uucp mail + + Rationale: + containes spool files for mail, printing, uucp transfer, etc. + May be a mount point for another volume. + +/usr/local Directory: + + Files: + NONE + + Directories: + bin lib etc man src + + Rationale: + contains files local to the specific system. will not be + modified by upgrade process. + +/usr/lib Directory: + + Files: + libc.a crt0.s {and as needed} + + Directories: + {none defined in spec} + + Rationale: + location for library files required for multi-user system + operation. This is the directory where program libraries + should reside. + +/usr/man Directory: + + Files: + NONE + + Directories: + man1 man2 man3 man4 man5 man6 man7 man8 + cat1 cat2 cat3 cat4 cat5 cat6 cat7 cat8 + + Rationale: + Contains manual pages for programs that are standard with + Linux. + +/usr/include Directory: + + Files: + {programmers include files} + + Directories: + {as needed} + + Rationale: + Standard place for system include files. + +/usr/src Directory: + + Files: + NONE + + Directories: + bin lib linux usr.bin usr.lib + + Rationale: + Contains source code for all applications in the release. + /usr/src/linux contains directories required for kernel builds. + +/usr/tmp Directory: + + Files: + NONE + + + Directories: + NONE + + Rationale: + Used as additional scratch space for programs. If /tmp is + a mounted file system, /usr/tmp may be a symbolic link to + /tmp. diff --git a/Linux-0.95/docs/linux-standards/Package_Draft b/Linux-0.95/docs/linux-standards/Package_Draft new file mode 100644 index 00000000..02a39e59 --- /dev/null +++ b/Linux-0.95/docs/linux-standards/Package_Draft @@ -0,0 +1,62 @@ +Please comment on the following document. + + [available as /pub/Linux/linux-standards/draft] + +Tommy Thorn (tthorn@daimi.aau.dk) writes (with my comments in [* ... *]): + +We need to make installation REAL SIMPLE AND FAST. I suggest the +following standard for distributing ported programs. + +Everything should be contained in a [compressed] tar file with a: + + - README, a short explanations of how this version differs from + the original, if it does, and how it was compiled. + + - PREREQUIST, again which kernel, but also which version of the + original. + +[* Let's call this PREREQ so we can all spell it *] + + - Makefile, not for compilation, but for installation!! After having + checked that you agree with paths and so, you just type 'make install' + perhaps as root. + + - Patches, context diff against the original. + + - Binaries + + - Optionally, manual pages, also with full path. + +Kernel patches should also be a [compressed] tar file containing: + + - README, describing what the patch does/is. + - PREREQUIST, a precise statement of which version of the + kernel the patches applies, and which, if any, patches that + was already applied. + +[* Begin Soap Box: + I don't think we should distribute kernel patches in the standard + release trees, unless there is a DEFINITE (fatal) bug fixed by the + patch. Most people are looking for an easy-to-build system with + binaries and sources that they can get up-and-running without much + trouble. Yes, we have to put together kernel patch kits, but we + need to have them coordinated (all patches in one common patchfile). + End Soap Box *] + +Sources belong in /usr/src, linux sources in /usr/src/linux, etc. + +Maybe we should split patches and binaries, but I don't like that, as you +would properbly end up having only one of either. + +[* It is my feeling that we should not distribute patches without the source + that the patches apply to. Often, someone will grab the wrong + "official" source, and the patches won't take. Then they make noises + about the patch not working. I feel that we should provide FULL + SOURCE to all programs, *WITH PATCHES APPLIED*. Leave the patches + in a _common_ directory under each source tree, ie: + + /usr/src/gcc/LINPAT/* + ^^^^^^ name subject to discussion + + to allow someone to see exactly what was changed, but also allow them + to compile without applying the patches themselves. *] diff --git a/Linux-0.95/docs/linux-standards/mail-archives b/Linux-0.95/docs/linux-standards/mail-archives new file mode 100644 index 00000000..f163126a --- /dev/null +++ b/Linux-0.95/docs/linux-standards/mail-archives @@ -0,0 +1,10041 @@ +From linux Wed Feb 5 09:14:43 1992 +Subject: Mail archive and Mirror information +To: linux-standards@concert.net +Date: Wed, 5 Feb 92 8:58:46 EST +Cc: linux-activists@joker.cs.hut.fi +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@concert.net + +I have started archiving the linux-standards mailing list to the anonymous +ftp archive on banjo.concert.net (/pub/Linux/linux-standards/mail-archives). + +Also, I am now mirroring: + tsx-11.mit.edu:/pub/linux + tupac-amaru.informatik.rwth-aachen.de:/pub/msdos/replace + athos.rutgers.edu:/pub/linux + nic.funet.fi:/pub/OS/Linux (when I can get in) + + into /pub/Linux/mirrors/* + +If there are any other sites that I should mirror, let me know. + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications +From linux Wed Feb 5 09:14:43 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <22115-0@banjo.concert.net>; Wed, 5 Feb 1992 09:14:07 -0500 +Received: from sumax.seattleu.edu + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA03625; + Wed, 5 Feb 92 09:14:03 -0500 +Received: by sumax.seattleu.edu id AA31383 (5.65a/IDA-1.4.2 + for linux-standards@concert.net); Wed, 5 Feb 92 06:16:20 -0800 +Date: Wed, 5 Feb 92 06:16:20 -0800 +From: Chuck Boyer +Message-Id: <9202051416.AA31383@sumax.seattleu.edu> +To: julian@jrc.flinders.edu.au, linux-standards@concert.net +Subject: Re: FS layout in Linux + +Thanks Julian, Miss Masey McMillon here. I like your ideas set out here +in your mail on directories. I vote for your suggestions. My concern is +that from the beginning I have taken from the various mails a certain +setup suggestion of partitions for Linux to be up and running; 4M for +the Root file system, whatever for the main Linux (I have 29M) and +an additional 8M for swap disk. So, having done that, I find that I +must put a lot of stuff in /usr (as I begin using the compiler for +third party stuff it looks for stuff in the headers and Makefiles...) +so will my 4M Root which has /usr on it (with /usr/bin and /usr/root +which has the dot.login files) be full too fast? So that sends me +seeking a way to mount 29M /tmp onto /usr instead, so I don't fear +running out of space. +Some information only. +thanks. + +From linux Wed Feb 5 12:21:31 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <23122-0@banjo.concert.net>; Wed, 5 Feb 1992 12:19:35 -0500 +Received: from p.lanl.gov by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA07680; Wed, 5 Feb 92 12:19:31 -0500 +Received: from zaphod.lanl.gov by p.lanl.gov (5.65/1.14) id AA24146; + Wed, 5 Feb 92 09:39:27 -0700 +Received: by zaphod.lanl.gov.lanl.gov (4.1/SMI-4.1) id AA05275; + Wed, 5 Feb 92 09:39:28 MST +Date: Wed, 5 Feb 92 09:39:28 MST +From: egdorf@zaphod.lanl.gov (Skip Egdorf) +Message-Id: <9202051639.AA05275@zaphod.lanl.gov.lanl.gov> +To: abc@concert.net +Cc: tthorn@daimi.aau.dk, julian@jrc.flinders.edu.au, + linux-standards@concert.net +In-Reply-To: Alan B Clegg's message of Wed, 5 Feb 92 8:30:08 EST <9202051337.AB20380@p.lanl.gov> +Subject: RE: FS layout in Linux + + + > /site is a nice idea + > /local nice too. + + Not sure about this one. Could someone please explain to me the difference + between /site and /local? I seem to have missed it. No need to send to the + group, private e-mail is fine [and stupid looks are STILL free]. + +As I am the originator of these, I will reply to the whole net. +We probably don't need both /site and /local on linux (??). +They are both hierarchys with bin, lib, etc. +On my network, /site is mounted from a server for the appropriate +architecture (eg sun3, sun4, PDP-11 :-) just as /usr is. +/local is used when a machine a) has a local disk b) has some special +hardware that needs a special version of a command. +The typical example is some program that uses graphics, and one machine +has a special graphics accelerator. The guiding principle is to allow +any user on the net to sit down at any machine and have a familier +environment. On one of the normal machines, the command "do-graphics" +gets the plain vanilla version from /site/bin. On the machine with +the accelerator, the command comes from /local/bin (before /site/bin in +PATH). In other words, /local allows the ability to override the SITE-wide +default command on a LOCAL machine. + + > Having seperate directories for each package i julian's sense + > (eg. ci co rcs .. in /app/rcs/bin) is a *very* bad idea. + + Yup. + +A *VERY* *VERY* bad idea. + + > What + > we need instead is way to shrink packages so that installation + > AND UNINSTALLATION is trivial. (eg. Interative Unix's approch + > or Next .pkg). + + Now, I'm not so sure about this.. How many packages are we looking at to start? + + When we start getting things like: UNIFY, Lotus 1-2-3, etc, then I agree. + But for now, [perhaps] tunnel vision is better... + +There is no reason to be short sighted unless the solution is hard. In +this case, the solution is easy. And there will be a LOT of packages. + +In my not-so-humble opinion, the single largest reason for lack of +acceptance of Unix in the commercial world is the difficulty of +selling a piece of shrink-wrapped software that just loads. This is +NOT because of SPARC vs 386 vs whatever. It is because nobody ever +made a simple standard that ALL third party commands go in /site/bin, +and ALL support files go in /site/lib (/site/lib/package/... is +perfectly acceptable as long as the libraries are rooted somewhere.) + +Take a look at framemaker sometime as an example. For any user to +use framemaker, the user must run a script that edits a PATH variable +into the user's .login!!! This, naturally fails for any user who +does anything even vaguely complex with PATH. Framemaker would not need +to do this if it could depend on something like /site/bin being in +every user's PATH and /site/lib being available for creation of +a /site/lib/frame/... + +I am not wedded to the name /site. I propose it because I am currently +using it, and because I believe that ANY scheme that can be agreed +upon will be better than the anarchy that now exists. + + Skip Egdorf + hwe@lanl.gov + +From linux Wed Feb 5 13:01:37 1992 +Return-Path: +Subject: RE: FS layout in Linux +To: egdorf@zaphod.lanl.gov (Skip Egdorf) +Date: Wed, 5 Feb 92 13:00:46 EST +Cc: abc@concert.net, tthorn@daimi.aau.dk, julian@jrc.flinders.edu.au +From: Alan B Clegg +Sender: abc@concert.net + + linux-standards@concert.net +In-Reply-To: <9202051639.AA05275@zaphod.lanl.gov.lanl.gov>; from "Skip Egdorf" at Feb 5, 92 9:39 am +X-Mailer: ELM [version 2.3 PL11] + +> > /site is a nice idea +> > /local nice too. + +> As I am the originator of these, I will reply to the whole net. +> We probably don't need both /site and /local on linux (??). +> They are both hierarchys with bin, lib, etc. + +Well, why not just call it /usr/local (pretty standard) and allow for the +future use of /usr/site. Seems that we might be a fair distance from NFS.. +[See end of message for full reasoning behind slight pessimism]. + +> In my not-so-humble opinion, the single largest reason for lack of +> acceptance of Unix in the commercial world is the difficulty of +> selling a piece of shrink-wrapped software that just loads. This is +> NOT because of SPARC vs 386 vs whatever. It is because nobody ever +> made a simple standard that ALL third party commands go in /site/bin, +> and ALL support files go in /site/lib (/site/lib/package/... is +> perfectly acceptable as long as the libraries are rooted somewhere.) + +Ok, Data General got around this with /var/pkg, with each package living in +/var/pkg, with links into /usr/bin [I believe, memory is fuzzy]. + +> Take a look at framemaker sometime as an example. + +I helped with the port of Framemaker 1.2 to the AViiON platform. It IS a mess, +but it resolves some problems. For those that are unfamiliar with the product, +it has a shell 'wrapper' that determines the type of platform that you are +running on, and then executes the correct binaries. This allows all of the +different versions of Framemaker to be loaded into the same directory tree +and be available via NFS from the same place for all archetectures. + +> I am not wedded to the name /site. I propose it because I am currently +> using it, and because I believe that ANY scheme that can be agreed +> upon will be better than the anarchy that now exists. + +I guess I am somewhat biased by my feeling that Linux will [and feel free to +flame me in private mail if you disagree] be 99% for hackers. I don't see +commercial vendors running to port their products to it. Please don't get me +wrong with this, I believe that Linux has great possibilities, but probably +won't rival SCO/ISC/BSD386/etc for the commercial market. [in fact, I don't +think that BSD386 will rival the others in the commercial market, but again, +that is my opinion]. + +UNIX Gurus[tm] have been trying to get this file system separation resolved +for *YEARS* and [obviously] have not yet gotten it [just] right. + +I am putting together a proposal for file system structure that I will post +tomorrow. At that point, have your red pens ready to mark up my thoughts. +I don't think we can solve the problems of the world [or even of just UNIX], +but I do think we need to get a decision made so that the next steps can +begin. + +-abc + +BTW: If you note, there has been a lot of heat about the malloc(0) not being + doing exactly what it does on other platforms, so I can imagine what + would occur if the 'standards' list came out with a directory structure + that was 'non-standard'... [grumble grumble] +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux Wed Feb 5 21:35:19 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <25355-0@banjo.concert.net>; Wed, 5 Feb 1992 21:34:25 -0500 +Received: from uceng.UC.EDU by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA15338; Wed, 5 Feb 92 21:34:22 -0500 +Received: by uceng.UC.EDU (16.6/1.34) id AA12842; Wed, 5 Feb 92 21:35:36 -0500 +From: strombrg@uceng.UC.edu (Dan Stromberg) +Message-Id: <9202060235.AA12842@uceng.UC.EDU> +Subject: Re: FS layout in Linux +To: linux-standards@concert.net +Date: Wed, 5 Feb 92 21:35:34 EST +X-Mailer: ELM [version 2.3 PL4] + + + Hi. + + Before I get started with specifics, let me spell out some of my +more general biases. + + First, background: + As we all know, many true's and'ed with a false, yield a false. + One true or'ed with many falses, is a true. + + IMO, there is a parallel here, between general socialism, and +software socialism. General socialism requires the "and of many true's", +with the ever-present likelihood of a false - that is, many people +who might like to make socialism work, messed up by a few more concerned +with themselves (this is an argument *against* general socialism, BTW). + Software socialism, seems to work in reverse. One good, +sturdy package, can dominate a market, over many good sturdy commercial +packages. + (Meanwhile, there will probably long be a market for people +who know how to install and improve those free packages. By the time +there isn't, we may well all be Eloi - cf. H.G. Well's +_Time_Machine_). + It is my opinion that the success of BSD Unix, is largely due +to the relatively free redistribution restrictions under which it +was placed. + Linux takes that further. It's quite redistributable, +if we ignore annoying little things like US export laws (I'm talking +about export, or even import-and-re-export, of DES routines - but that's +only of tangential relevance here in the US, and matters still less to +a site like nic.funet.fi). + Anyway. + To sum up the more political bit of my rambling, before I +completely lose your interest: I think linux may well really take off, +if one of the many free MACH-based packages doesn't gain critical mass +first. Even if one does, there may still be a place for a small +SysVish system. + One consequence of a system being in the domain of hackers, +as BSD has been, is that it will tend to mature into something fairly +useable, if not pretty nice. Given that there's even so much as a +marginal possibility of linux becoming fairly substantial, we would do +the industry a service, to plan a bit beyond our expectations. I'll +spare you the analogies with what MS-DOS has become to the field. + + + + Following, are my ideas on the file system, with the above +points in mind. + + The idea of a small root partition, with just enough to get +everything else rolling, is to be protected. It makes fsck'ing on +reboot nicer, to say nothing of the reduced complexity in getting +a dead system back up. + + /bin and /usr/bin, I'd like to see distinct, in part to keep +the minimal-initial-system, and in part because it breaks things to +do otherwise, like the Kerberos Version IV "make install". + + I think S. Egdorf was really onto something, with the use of: +{/,/usr,/site,/local}{/bin,/etc,/lib}. + If we could ignore our past, something like: +{/,/multiuser,/multiuser/package}{/executable,/data}{,/site,/local} +might be nicer still, but I can't pretend to believe something that +idealistic would gain much acceptance. I think we can change +the fs tree a bit, given the indirection provided by $PATH, but +something like this would probably just be too "different", and +indeed, somewhat gratuitously so. + + I agree with tytso, that "etc" has taken on connotations of +"important system files", and should probably be avoided, except on +root. "lib" should do. + + What's the rationale behind putting "linux" in pathnames? +I'm inclined to believe we'd have better luck with a standard fs tree, +if we avoided that word in paths. I have *nothing* against linux +itself, or its name. But will there be anything that is truly +linux-specific, on the system, but the source code? + + PATH, LIBPATH, MANPATH, and INCLUDEPATH are each quite worth +having, IMO. + + I agree that user's don't absolutely have to have system +files in the same place, on every machine. The standard distribution +should be pretty consistent, and should provide guidelines for growth, +but PATH's are precisely the needed extra level of indirection. I +realize this ignores bad habits like hard coding /usr/local/lib/gcc-cpp +into an executable. An env var should be used, or, another name used +("gcpp"), if it really cannot be put first on the path, with the same +old name. + In gcc's case, I like the idea of a cc'ish frontend, that changes +the PATH and LIBPATH as needed, to get gcc used - on systems that aren't +using gcc as the primary compiler. 'just an example. + Of course all of my #!/usr/local/bin/bash scripts aren't going +anywhere in a hurry... But somehow I'd rather see bash going in /usr/bin, +or even /bin, than put standard stuff in a "local" directory. In fact, +I rather favor the idea of a stripped down, bournish bash put in /bin, +and a full fledged, gigundus bash in /usr/bin - one for scripts, and +one loaded with interactive features. (I'd like to see Byron's rc +in /bin, too... but sadly, making it the primary shell for system scripts +would probably be going too far). + + Is there a workable alternative to #! ? It's valuable, but it's +a *hack*. Someday, someone should implement a #$ that scans a (optionally +intrascript specified) path for the proper interpreter. Or perhaps, it +should be incorporated into the file system, as is being done with ACL's... +It might make sense to tackle both at the same time, with the addition of +an abstraction for "whatever's associated with this file" for tar's sake. + + A couple of people have mentioned proprietary methods of +installing and uninstalling packages. I'm familiar with SCO's custom, +myself - but it didn't strike me as much of a solution, to +sometimes-complicated installations. Packages that are intended to +*partially* replace the functionality of other packages, would not +necessarily work well, with installation programs that reach into +/usr/bin and such. + I realize people have been saying lots of separate directories +is a very bad idea, but I've seen no rationales presented. I'm open to +be being persuaded otherwise, but honestly I currently like the idea of +separate directories, for each package. Such is the method being used +on our primary fileserver at the univ of cinti engineering dept, and +it seems to work well. + I've *no* problems with it's speed, and the provided orthogonality +is elegant. The fileserver is admittedly fast, but the PATH searches +are almost exclusively done on slower machines, via network communication. +The fact that many shells (including bash) hash paths, and that the VFS +would allow nonlinear searches of directories, support the idea as well. +In fact, the C library could be easily changed to do non-linear scanning +of PATHs, as well, taking care not to cache *too* much information. As +UNIX grows, this will only become more important. + I think both a "custom" program, *and* separate directories, is +called for, in order to hack in and out those pesky inetd.conf entries, +and such. But the more simplistic the custom program, the better. I'd +hate to see things written for a custom program starting to outsmart each +other - EG, imagine the problems associated with (de)installing two +packages, both intended to replace intersecting but non-identical portions +of a third... especially if they try to rename pieces of the third, +so they can fall back on the old versions... + + Back to the fs tree: + I think my ideal system, for both my own personal use, and for a +large site, would look like: + +/ home for root. +/dev How could we ever forget this? :-) +/bin minimal executables for single user operation +/etc system configuration stuff. The traditional. +/lib libraries for single user-only use. Maybe someday a small + terminfo database, so we could put a full screen editor or + two in /bin? Actually, that might be about *all* that + needs to go here... and that could get stuffed into /etc. +/usr mounted in /etc/rc. Little to nothing but mount points here. +/usr/bin system executables for multiuser mode. +/usr/lib system datafiles for multiuser mode. +/usr/home home directories, or mount points for disks with users.... +/usr/app Little to nothing but mount points. +/usr/app/name where 'name' is the name of a package + + /usr/bin and /usr/lib, would be there for old installation +scripts. They should be deprecated, IMO. I'd actually be pretty +happy to see a distributed system with present, but empty, /usr/bin +and /usr/lib. + Termcap could be an app. Terminfo could be an app. gcc +could be an app, to make room for any other compilers that may be +coming. Shell-of-the-month's that aren't trusted enough for system +scripts, could be apps. The idea is that no piece of software is really +central to the system's existence. Ok, init and /bin/sh probably +should, though the sh is arguable. + Ideally, /,/bin,/etc, /lib, and /dev could be copied to a +(moderately sized) floppy filesystem, to get another system running +enough to de-tar an entire distribution from diskettes/tapes/cd-roms/ +network, and edit some config files, or invoke some simplistic +installation scripts/binaries. + In fact, a really nicely polished system might have two +password files: one for single user mode, on root, and one for multiuser, +on /usr somewhere, maybe /usr/etc. I'm less than happy about the +number of systems I've seen, that had /etc/passwd (and attendant +databases), outgrow their root partition. Putting just logins +for root, system accounts, and sysadmins in /etc/passwd (perhaps only +these would be allowed to log in on the console), and the bulk of +users in /usr/etc/passwd, would be kind of nice. + + My comments on the filesystem layout are done. + + S. Egdorf has mentioned that much of the reason for UNIX's +lack of acceptance, is its lack of shrink-wrapped software. I support +his conclusion (that /site in some form, make sense, though it +could be replaced fully or in part, but /usr/app), but not his +reasoning... IMO, this is technically, and politically (I'll not get +started again...) a reason for UNIX's resilience, as well. + The fact that we don't have something as constrictive as +the BIOS hampering UNIX's growth, is in part a strength. POSIX +is testament to the flexibility, and viability, of a Better Way. + Honestly, I shudder at all the emphasis that's been put +on ABI's lately. It's great for distribution, but it's harmful to +flexibility. ...and what we're seeing is the same problems hashed +out, more cryptically. In the C world, we worry that we don't +have functions present with names like "strrchr". In the ABI world, +we have to concern ourselves with missing system calls, often identified +by *numbers*. Semantically, I believe they almost identical, but one +is considerably less mnemonic, and much more given to being used for +multiple, conflicting purpose. + IMO, it makes far more sense to compile ML or Eiffel or whatever, +into ANSI C, extended just enough to allow symbolic debugging of the +source language. + Writing or compiling to portable C, isn't all *that* hard... +It's just an unfortunate part of the C tradition, not to. + + Anyway. Those're my thoughts. + +(Skip, you get my vote for best contribution to the layout discussion, +*and* most emperor's-new-clothes idea. That's something of an Honour, +IMO - no sarcasm whatsoever) + + +From linux Thu Feb 6 09:18:34 1992 +Return-Path: +Subject: DRAFT of File System document +To: linux-standards@concert.net +Date: Thu, 6 Feb 92 9:17:37 EST +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@concert.net + +Please let me know what you think of this [pro and con arguments are requested] + +=====SNIP HERE===== +The following is being submitted by Alan Clegg [abc@concert.net] as the +proposed standard for directory file structure under Linux. + +Complete implementation of this file structure is completely voluntary, +and will not be enforced, but will be recommended. This specification +is released as guidelines for people porting and writing software for +the Linux Operating System to allow easy software installation, upgrade, +and tailoring on already installed systems. + +Root Directory: + + Files: + {none defined by spec} + + Directories: + bin dev etc lib mnt usr + + Rationale: + The root directory should not be cluttered with files or + directories, and should contain no user programs. + +/bin Directory: + + Files: + sh init mount umount dd cat ls fsck [?others?] + [should ls be there if 'echo *' works?] + + Directories: + {none defined by spec} + + Rationale: + The /bin directory should contain programs that are vital + to the restoration of other file systems in the case of + a corrupting crash. No executable in /bin should require + any other file system to be mounted to execute correctly. + +/dev Directory: + + Files: + {device files} + + Directories: + {none define by spec} + + Rationale: + Standard UNIX[tm] device files. This directory should contain + device entries for all devices that are supported in the + standard kernel, even if the hardware device does not exist + on the system. [comments?] + +/etc Directory: + + Files: + mtab passwd rc ttytab {and as needed} + + Directories: + {none defined by spec} + + Rationale: + Standard location of files required during system boot. Files + in this directory are usually system specific. Most will + require human intervention during system upgrade. + +/lib Directory: + + Files: + {libraries required for system initialization} + + Directories: + {none defined by spec} + + Rationale: + To keep the size of the root partition small (if separate from + /usr), the files in this directory should only be ones required + by files in the root partition. + +/mnt Directory: + + Files: + NONE + + Directories: + NONE + + Rationale: + Standard mount point for external (transient) file systems. + Must be available for sub-system installation. Should remain + as an empty directory. + +/tmp Directory: + + Files: + NONE + + Directories: + NONE + + Rationale: + Temporary file space available for general program use. May + become a mounted partition upon system boot. [Minimum size?] + +/usr Directory: + + Files: + {none defined by spec} + + Directories: + adm bin spool local lib etc man include src tmp linux users + + Rationale: + /usr is the mount point for the second major (after root) + hierarchy of file structure and is discussed in the next + section. + +/usr/adm Directory: + + Files: + {none defined in spec} + + Directories: + {none defined in spec} + + Rationale: + Location of log files and accounting information. + +/usr/bin Directory: + + Files: + {all files from standard distribution not contined in /bin} + + Directories: + {none defined in spec} + + Rationale: + contains 'drop-in' executables that are considered to be + standard to the UNIX system. These files should NOT be + Linux specific, but should have the same function as their + UNIX equivalents. + +/usr/etc Directory: + + Files: + {none defined in spec} + + Directories: + {none defined in spec} + + Rationale: + contains configuration files for any files in /usr/bin. helps + to keep /etc clean and small. + +/usr/spool Directory: + + Files: + {none defined in spec} + + Directories: + uucp mail + + Rationale: + containes spool files for mail, printing, uucp transfer, etc. + May be a mount point for another volume. + +/usr/local Directory: + + Files: + {none defined in spec} + + Directories: + bin lib etc man src + + Rationale: + contains files local to the specific system. will not be + modified by upgrade process. + +/usr/lib Directory: + + Files: + libc.a crt0.s {and as needed} + + Directories: + {none defined in spec} + + Rationale: + location for library files required for multi-user system + operation. This is the directory where program libraries + should reside. + +/usr/man Directory: + + Files: + NONE + + Directories: + man1 man2 man3 man4 man5 man6 man7 man8 + + Rationale: + Contains manual pages for programs that are standard with + Linux. + +/usr/include Directory: + + Files: + {programmers include files} + + Directories: + {as needed} + + Rationale: + Standard place for system include files. + +/usr/src Directory: + + Files: + NONE + + Directories: + bin lib linux usr.bin usr.linux + + Rationale: + Contains source code for all applications in the release. + /usr/src/linux contains directories required for kernel builds. + +/usr/tmp Directory: + + Files: + NONE + + + Directories: + NONE + + Rationale: + Used as additional scratch space for programs. If /tmp is + a mounted file system, /usr/tmp may be a symbolic link to + /tmp. + +/usr/linux Directory: + + Files: + NONE + + Directories: + bin lib etc + + Rationale: + Contains programs that are "linux specific" and programs that + semantics are different from the standard UNIX usage. + +/usr/users Directory: [Probably /home] + + Files: + NONE + + Directories: + {one for each user, except root} + + Rationale: + Users home directories. [Root's home directory should be + on the root partition somewhere.] + +=====SNIP HERE===== + +Please feel free to comment on these ideas, and let me know what you think. +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux Thu Feb 6 10:16:12 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <27511-0@banjo.concert.net>; Thu, 6 Feb 1992 10:15:19 -0500 +Received: from wrzx01.rz.uni-wuerzburg.de + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA19251; + Thu, 6 Feb 92 10:14:45 -0500 +Received: from winx13.informatik.uni-wuerzburg.de + by wrzx01.rz.uni-wuerzburg.de (4.1/uniwue-M-2.02) id AA01950; + Thu, 6 Feb 92 16:13:54 +0100 +Received: by winx13.informatik.uni-wuerzburg.de (4.1/uniwue-C-2.0) id AA26668; + Thu, 6 Feb 92 16:13:36 +0100 +From: Dirk Hohndel +Message-Id: <9202061513.AA26668@winx13.informatik.uni-wuerzburg.de> +Subject: Re: DRAFT of File System document +To: linux-standards@concert.net +Date: Thu, 6 Feb 92 16:13:36 MET +In-Reply-To: <9202061431.AA13629@winx03.informatik.uni-wuerzburg.de>; from "Alan B Clegg" at Feb 6, 92 9:17 am +X-Mailer: ELM [version 2.3 PL0] + +Alan B Clegg writes +> +> Root Directory: +> + +ok + +> +> /bin Directory: +> +> Files: +> sh init mount umount dd cat ls fsck [?others?] + +programs to set up / check networking (a la ifconfig) + +> [should ls be there if 'echo *' works?] + +maybe yes, some options of ls might be useful in single user mode + +> Rationale: +> The /bin directory should contain programs that are vital +> to the restoration of other file systems in the case of +> a corrupting crash. No executable in /bin should require +> any other file system to be mounted to execute correctly. + +Good point + +> +> /dev Directory: +> +> Rationale: +> Standard UNIX[tm] device files. This directory should contain +> device entries for all devices that are supported in the + ^^^ +> standard kernel, even if the hardware device does not exist +> on the system. [comments?] + +Why ? a minimal configuration doesn't need devices for tape, scanner, 16 COMs +8 LPTs 15 disks and so on + +> +> /etc Directory: +> +> Files: +> mtab passwd rc ttytab {and as needed} + +group hosts (!) printcap + +> +> /lib Directory: + +ok + +> +> /mnt Directory: + +ok + +> +> /tmp Directory: + +ok + +> /usr/adm Directory: +> +> Files: +> {none defined in spec} + +adduser, rmuser and related stuff ? +> +> Directories: +> {none defined in spec} +> +> Rationale: +> Location of log files and accounting information. +Maybe programms of administrative charakter not needed in single user mode ? + +> +> /usr/bin Directory: +> +> Rationale: +> contains 'drop-in' executables that are considered to be +> standard to the UNIX system. These files should NOT be +> Linux specific, but should have the same function as their +> UNIX equivalents. +maybe gcc should be HERE ! + +> +> /usr/etc Directory: +> + +ok + +> /usr/spool Directory: + +ok + +> +> /usr/local Directory: +> +> Files: +> {none defined in spec} +> +> Directories: +> bin lib etc man src +> +> Rationale: +> contains files local to the specific system. will not be +> modified by upgrade process. + +does that meen that in our standard release this directory is empty ? + +> +> /usr/lib Directory: +> +> Rationale: +> location for library files required for multi-user system +> operation. This is the directory where program libraries +> should reside. + +what about shared libs ? + +> +> /usr/man Directory: +> + +ok + +> +> /usr/include Directory: +> + +ok + +> +> /usr/src Directory: +> +> Rationale: +> Contains source code for all applications in the release. +> /usr/src/linux contains directories required for kernel builds. + +good idea + +> +> /usr/tmp Directory: + +ok + +> +> /usr/linux Directory: + +ok + +> /usr/users Directory: [Probably /home] + +this should not be ruled, because we should force (urge, beg,...) people to +leave their habbit. I think someone is used to /home/joe the otherone to +/u/joe or anything else + + +All in all : accepted !! + +Dirk + +-- + Dirk Hohndel Lehrstuhl fuer Informatik I + hohndel@informatik.uni-wuerzburg.de Universitaet Wuerzburg + Tel. 0931 / 888-5057 Am Hubland + Fax. 0931 / 888-4600 D-8700 Wuerzburg + +From linux Thu Feb 6 10:21:58 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <27584-0@banjo.concert.net>; Thu, 6 Feb 1992 10:21:21 -0500 +Received: from daimi.aau.dk by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA19475; Thu, 6 Feb 92 10:21:17 -0500 +Received: from bentley.daimi.aau.dk by daimi.aau.dk + with SMTP (5.61++/IDA-1.2.8) id AA03550; Thu, 6 Feb 92 16:19:42 +0100 +Received: by bentley.daimi.aau.dk (5.64/1.34) id AA17286; + Thu, 6 Feb 92 16:19:36 +0100 +From: poe@daimi.aau.dk +Message-Id: <9202061519.AA17286@bentley.daimi.aau.dk> +Subject: Re: FS layout in Linux +To: strombrg@uceng.UC.edu (Dan Stromberg) +Date: Thu, 6 Feb 92 16:19:33 MET +Cc: linux-standards@concert.net +In-Reply-To: <9202060235.AA12842@uceng.UC.EDU>; from "Dan Stromberg" at Feb 5, 92 9:35 pm +Organization: DAIMI, Computer Science Department of Aarhus University +Phone: 86 20 27 11 - 5034 +X-Mailer: ELM [version 2.3 PL11] + +> Hi. +> +> Before I get started with specifics, let me spell out some of my +> more general biases. +> + + [political stuff deleted] + +> +> Following, are my ideas on the file system, with the above +> points in mind. +> +> The idea of a small root partition, with just enough to get +> everything else rolling, is to be protected. It makes fsck'ing on +> reboot nicer, to say nothing of the reduced complexity in getting +> a dead system back up. +> +> /bin and /usr/bin, I'd like to see distinct, in part to keep +> the minimal-initial-system, and in part because it breaks things to +> do otherwise, like the Kerberos Version IV "make install". +> +> I think S. Egdorf was really onto something, with the use of: +> {/,/usr,/site,/local}{/bin,/etc,/lib}. + +Agreed. + +> If we could ignore our past, something like: +> {/,/multiuser,/multiuser/package}{/executable,/data}{,/site,/local} +> might be nicer still, but I can't pretend to believe something that +> idealistic would gain much acceptance. + +Ideal, hmmmph. + +> PATH, LIBPATH, MANPATH, and INCLUDEPATH are each quite worth +> having, IMO. + +Certainly. + +> +> Is there a workable alternative to #! ? It's valuable, but it's +> a *hack*. Someday, someone should implement a #$ that scans a (optionally +> intrascript specified) path for the proper interpreter. Or perhaps, it +> should be incorporated into the file system, as is being done with ACL's... +> It might make sense to tackle both at the same time, with the addition of +> an abstraction for "whatever's associated with this file" for tar's sake. + +Ugh! #! must only accept an absolute path for the interpreter, or you open +a can of worms, securitywise. + +> Back to the fs tree: +> I think my ideal system, for both my own personal use, and for a +> large site, would look like: +> +> / home for root. +> /dev How could we ever forget this? :-) +> /bin minimal executables for single user operation +> /etc system configuration stuff. The traditional. +> /lib libraries for single user-only use. Maybe someday a small +> terminfo database, so we could put a full screen editor or +> two in /bin? Actually, that might be about *all* that +> needs to go here... and that could get stuffed into /etc. +> /usr mounted in /etc/rc. Little to nothing but mount points here. +> /usr/bin system executables for multiuser mode. +> /usr/lib system datafiles for multiuser mode. +> /usr/home home directories, or mount points for disks with users.... +> /usr/app Little to nothing but mount points. +> /usr/app/name where 'name' is the name of a package +> +> /usr/bin and /usr/lib, would be there for old installation +> scripts. They should be deprecated, IMO. I'd actually be pretty +> happy to see a distributed system with present, but empty, /usr/bin +> and /usr/lib. + +I don't really see anything wrong with /usr/lib and /usr/bin. + +> Termcap could be an app. Terminfo could be an app. gcc +> could be an app, to make room for any other compilers that may be +> coming. Shell-of-the-month's that aren't trusted enough for system +> scripts, could be apps. The idea is that no piece of software is really +> central to the system's existence. Ok, init and /bin/sh probably +> should, though the sh is arguable. + +Does this mean that termcap and terminfo should be programs (applications? :-) +or shuld they just reside in /usr/app + +> Ideally, /,/bin,/etc, /lib, and /dev could be copied to a +> (moderately sized) floppy filesystem, to get another system running +> enough to de-tar an entire distribution from diskettes/tapes/cd-roms/ +> network, and edit some config files, or invoke some simplistic +> installation scripts/binaries. + +Good idea. + +> In fact, a really nicely polished system might have two +> password files: one for single user mode, on root, and one for multiuser, +> on /usr somewhere, maybe /usr/etc. I'm less than happy about the +> number of systems I've seen, that had /etc/passwd (and attendant +> databases), outgrow their root partition. Putting just logins +> for root, system accounts, and sysadmins in /etc/passwd (perhaps only +> these would be allowed to log in on the console), and the bulk of +> users in /usr/etc/passwd, would be kind of nice. + +Never heard of YP^H^H NIS? + +> My comments on the filesystem layout are done. +> +> S. Egdorf has mentioned that much of the reason for UNIX's +> lack of acceptance, is its lack of shrink-wrapped software. I support +> his conclusion (that /site in some form, make sense, though it +> could be replaced fully or in part, but /usr/app), but not his +> reasoning... IMO, this is technically, and politically (I'll not get +> started again...) a reason for UNIX's resilience, as well. +> The fact that we don't have something as constrictive as +> the BIOS hampering UNIX's growth, is in part a strength. POSIX +> is testament to the flexibility, and viability, of a Better Way. + +Does anyone really think we will ever have shrik-wrapped apps. for linux?? + +I view linux as a hackers system, where we can have source for everything, and +not have to rely on shrinkwrapped binaries-only packages. + +On another note, beware of the tendency to make linux an "design by commitee" +system. I belive that linux is as good as it is, because it was designed and +implemented by one man (Linus). This doesn't mean that we should stop making +contributions and extensions, as Linus can't do everything for us. + +Trying to forge standards at this early stage seems a bit futile to me, +time will tell where linux goes.... (This will probably make my mailbox +bloat with flames, Oh well..) + + - Peter. + +From linux Thu Feb 6 10:34:30 1992 +Return-Path: +Subject: Re: DRAFT of File System document +To: linux-standards@concert.net +Date: Thu, 6 Feb 92 10:33:52 EST +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@concert.net + +> > /bin Directory: +> > sh init mount umount dd cat ls fsck [?others?] +> programs to set up / check networking (a la ifconfig) +Yes, I could not think of all the possibilities, just be sure that they fit +in with the Rationale... 8-) + +> > [should ls be there if 'echo *' works?] +> maybe yes, some options of ls might be useful in single user mode +Agreed. + +> > /dev Directory: +> > +> > Rationale: +> > Standard UNIX[tm] device files. This directory should contain +> > device entries for all devices that are supported in the +> ^^^ +> > standard kernel, even if the hardware device does not exist +> > on the system. [comments?] +> +> Why ? a minimal configuration doesn't need devices for tape, scanner, 16 COMs +> 8 LPTs 15 disks and so on + +Right. Probably don't need all of 'em.. + +> > /usr/adm Directory: +> > Files: +> adduser, rmuser and related stuff ? +Yup.. but gotta wait till someone ports them.. 8-) + +> > Rationale: +> > Location of log files and accounting information. +> Maybe programms of administrative charakter not needed in single user mode ? + +Well, yes-and-no. Perhaps these files should really reside in /usr/bin? +This is where the call gets hard to make. + +> > /usr/bin Directory: +> maybe gcc should be HERE ! +Yes! + +> > /usr/local Directory: +> > Rationale: +> > contains files local to the specific system. will not be +> > modified by upgrade process. +> does that meen that in our standard release this directory is empty ? + +Yes. + +> > /usr/lib Directory: +> what about shared libs ? +Dunno.. where *DO* they live? I would assume that /usr/lib is the right place. + +> > /usr/users Directory: [Probably /home] +> this should not be ruled, because we should force (urge, beg,...) people to +> leave their habbit. I think someone is used to /home/joe the otherone to +> /u/joe or anything else + +None of these are rules, since I know that everyone is *VERY* opinionated. +I have taken the best arguments for each of the file systems and come up with +this. It seems that it is very close to the BSD 4.3 structure (although I +don't have access to one of them to check it out). + +> All in all : accepted !! + +Thanks, +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux Thu Feb 6 14:24:20 1992 +Return-Path: +Subject: Re: DRAFT of File System Document +To: linux-standards@concert.net +Date: Thu, 6 Feb 92 14:24:03 EST +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@concert.net + +EEEEEeeeeekkkk! + +The list of files in each directory was a *SAMPLE*. I was not meaning to list +every single file... that will come later. + +I must say, so-far, the comments have been very positive. Thanks! + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux Thu Feb 6 14:25:20 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <28924-0@banjo.concert.net>; Thu, 6 Feb 1992 14:22:35 -0500 +Received: from tsx-11.MIT.EDU by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA23545; Thu, 6 Feb 92 14:22:33 -0500 +Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA22168; + Thu, 6 Feb 92 14:22:12 -0500 +Date: Thu, 6 Feb 92 14:22:12 -0500 +From: eichin@ATHENA.MIT.edu ("Mark W. Eichin") +Message-Id: <9202061922.AA22168@tsx-11.MIT.EDU> +To: abc@concert.net +Cc: linux-standards@concert.net +In-Reply-To: Alan B Clegg's message of Thu, 6 Feb 92 9:17:37 EST <9202061449.AA16809@MIT.EDU> +Subject: re: DRAFT of File System document + +Overall it looks good; I've got a few comments on specific sections... + +/bin Directory: +> Rationale: +> The /bin directory should contain programs that are vital +> to the restoration of other file systems in the case of + Add mknod to the list? if you lose some device (or change the +kernel in such a way that device numbers change) you're really going +to need it... + +/dev Directory: + Many Unix systems also put MAKEDEV in here - a shell script +which takes "common names" as arguments and creates the devices to +match (ie. MAKEDEV pty 8 will make the first 8 pty master/slave +pairs.) + +/etc Directory: +> Rationale: +> Standard location of files required during system boot. Files + I believe the convention here has evolved to *configuration* +files need at boot time; the rc files are a special case, since they +are config files but they happen to be executable... Otherwise, there +are really no programs that belong in etc. + +/usr/tmp: +> Rationale: +> Used as additional scratch space for programs. If /tmp is +> a mounted file system, /usr/tmp may be a symbolic link to +> /tmp. + On most Unix systems I'm familiar with, there is an important +semantic distinction between /tmp and /usr/tmp which precludes the use +of a symlink: /tmp is cleaned at boot time, /usr/tmp isn't. Thus, many +programs keep "autosave" files in /usr/tmp (there are very good +reasons not to keep them in the same directory as the original, for +example if the original is a *slow* (ie. networked) or nearly full +file system, you take a real hit when doing autosaves -- but you want +to do them as often as you can get away with...) + +/usr/linux Directory: +> Rationale: +> Contains programs that are "linux specific" and programs that +> semantics are different from the standard UNIX usage. + This sounds bad for the same reason that "/usr/ucb" is -- that +there isn't anything truly "linux specific". Can you name things that +really should go here? + As for "different" programs, that'll just be a reason for me +*not* to have /usr/linux/bin in my path... + +/usr/local Directory: + Well, I suppose this is the right thing to do at this level, +but let me tell a few stories from my experiences... + 1) At Cygnus Support, internally we have three categories of +installed packages: "latest", "vintage", and "unsupported". Latest and +vintage typically have overlapping contents; latest is whatever got +most recently compiled, whereas vintage is the "long term stable" +version. "unsupported" means anything we're not paid to support (for +example, X11 ends up here, as unsupported/X11/{bin,lib...}; most +things off the net end up here.) We specifically don't *have* a +/usr/local because so many things come off the net with /usr/local +hard coded, and we have to find those paths ourselves (our customers +to install our packages under /usr/cygnus - we can't preempt their +/usr/local.) + 2) At MIT (Project Athena), *everything* is out on the net (it +is a pain to update a full software load on 1K workstations, so only +the base OS is on them.) There are different size packages, from the +full Athena setup (which gets put under one mountpoint, so that +symlinks from the workstation local disk get "filled in") to smaller +"lockers", some of which have groups of programs (such as the "gnu" +locker), and some of which have single programs (such as the lockers +for saber, calendar, S...). For consistency, lockers all go under the +/mit directory (which is, granted, very provincial :-) however, there +is an "add" alias which automatically adds the locker's bin directory +to the user's path. This leads to some extensive paths; mine only has +17 elements in it, but I haven't been using many packages this +session. The path length is not usually a major performance problem, +at least for executable searches, partially because of the hashed +directory cache in the shell; "man" sometimes gets slow, particularly +when it *doesn't* find the name because you misspelled it and has to +search 10 directories per path entry for the rest. [Summary: don't be +afraid of long paths.] /usr/local just isn't general enough to cover +this, though it gets used occasionally on "private" workstations. + As for the base operating system, some work was done on +minimizing the contents of the root (so that fast local disk could be +more profitably used as swap, tmp, and AFS cache space) so some +interesting distinctions were made (and *lots* of symlinks...) For +example, /bin contained things that had to be on the root; /usr/bin +contained things that didn't. (Recently, /usr/athena/{bin,lib,etc} +were also added to cover things that Athena was specifically +responsible for rather than scattering them elsewhere in the +filesystem.) + + Another story: if you've kept up with Plan 9 from Bell Labs, +their shell ("rc" - and I mean the Plan 9 version, *not* the clone +available on the net) *doesn't* support a PATH. All executables are in +/bin; you just "mount" other directories "after" /bin, so that the +filesystem shows /bin as one (very long) directory. This is going +somewhat in the other direction (and is not very practical to us, as +Linux doesn't support union directories [nor does any operating system +other than Plan 9 as far as I know]) but has some merit to it. (These +"mounts" are entirely per process, not system wide, though your child +processes inherit them.) + + _Mark_ N1DPU + MIT Student Information Processing Board + Cygnus Support + +From linux Thu Feb 6 14:52:21 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <29065-0@banjo.concert.net>; Thu, 6 Feb 1992 14:51:31 -0500 +Received: from istwok.ods.com (twok.ods.com) + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA23686; + Thu, 6 Feb 92 14:51:26 -0500 +Received: by istwok.ods.com id AA04010 (5.65c/IDA-1.3.5); + Thu, 6 Feb 1992 13:52:11 -0600 +From: David Engel +Message-Id: <199202061952.AA04010@istwok.ods.com> +Subject: Re: DRAFT of File System document +To: abc@concert.net (Alan B Clegg) +Date: Thu, 6 Feb 92 13:52:10 CST +Cc: linux-standards@concert.net +In-Reply-To: <199202061424.AA00343@istwok.ods.com>; from "Alan B Clegg" at Feb 6, 92 9:17 am +X-Mailer: ELM [version 2.3 PL11] + +> Root Directory: +> +> Files: +> {none defined by spec} + +For those who boot from the hard disk (using shoelace or whatever), we +probably want to put the kernel itself here. We probably also want to +give it a "standard" name so programs like ps can get information from +it when /dev/kmem is implemented. + +David + +From linux Thu Feb 6 16:03:17 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <29648-0@banjo.concert.net>; Thu, 6 Feb 1992 16:02:35 -0500 +Received: from golem.wcc.govt.nz by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA24819; Thu, 6 Feb 92 16:01:53 -0500 +Received: from csc.wcc.govt.nz by golem.wcc.govt.nz id ; + Fri, 7 Feb 92 10:03:32 +1300 +Received: by csc.wcc.govt.nz (MX V3.0) id 1045; Fri, 07 Feb 1992 10:03:54 EST +Sender: hamilton +Date: Fri, 07 Feb 1992 10:03:28 EST +From: hamilton@csc.wcc.govt.nz +To: linux-standards@concert.net +Cc: hamilton@csc.wcc.govt.nz +Message-Id: <00955CBC.F0614000.1045@csc.wcc.govt.nz> +Subject: FS layout in Linux + + +I thought that Theodore Ts'o (tytso@athena.mit.edu) made a very good +point about a large number of hierarchies off root being a problem. +Any decisions "we" make have to consider the typical target platform. +And I agree also agree with his statement that sym links can be a +source of confusion. We use the following for local stuff: + +On our two small AIX and Ultrix boxes we have the following scheme + +/usr/local/app/ +/usr/local/users/ +/usr/local/bin/ +/usr/local/lib/ +/usr/local/etc/ +/usr/local/README + +We try to stick ALL local stuff as possible somewhere under /usr/local. +It then becomes quite easy to put all local (frequently changing stuff) +in the same partition. It also simplifies backups and upgrades - we +take extra care to backup /usr/local. + +I don't have strong opinions on the fs hierarchy - I'm not pushing our +this particular scheme - I just thought I add another possibility into +the melting pot. + +The one thing I would like to push is some strategic (perhaps +standardised) placement of README files around the hierarchy where I +can find out the logic and convensions contained within (plus misc +general notes). +________________ +Michael Hamilton, Computer Services Section, Wellington City Council, P.O. Box +2199, Wellington, New Zealand. Phone: (64) (4) 801-3317 FAX: (64) (4) 801-3020 +Domain: hamilton@csc.wcc.govt.nz PSImail: PSI%0530147000090::HAMILTON + + + +From linux Fri Feb 7 17:03:13 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <7024-0@banjo.concert.net>; Fri, 7 Feb 1992 17:02:36 -0500 +Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com) + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA07554; + Fri, 7 Feb 92 17:02:08 -0500 +Received: by dg-rtp.dg.com (5.4/dg-rtp-proto) id AA20790; + Fri, 7 Feb 1992 17:02:01 -0500 +Received: by ponds.UUCP (smail2.5) id AA10822; 7 Feb 92 16:40:16 EST (Fri) +To: dg-rtp!concert.net!linux-standards-request@concert.net, + linux-standards@concert.net +Subject: Re: DRAFT of File System document +Message-Id: <9202071640.AA10818@ponds.UUCP> +Date: 7 Feb 92 16:40:16 EST (Fri) +From: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers) + + +Shared libraries live in /shlib on ISC; and in /lib on HP/UX. + + +From linux Sun Feb 9 11:34:32 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <10347-0@banjo.concert.net>; Sun, 9 Feb 1992 11:33:49 -0500 +Received: from uceng.UC.EDU by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA11023; Sun, 9 Feb 92 11:33:45 -0500 +Received: by uceng.UC.EDU (16.6/1.34) id AA26276; Sun, 9 Feb 92 11:32:31 -0500 +From: strombrg@uceng.UC.edu (Dan Stromberg) +Message-Id: <9202091632.AA26276@uceng.UC.EDU> +Subject: Re: FS layout in Linux +To: poe@daimi.aau.dk +Date: Sun, 9 Feb 92 11:32:28 EST +Cc: linux-standards@concert.net +In-Reply-To: <9202061519.AA17286@bentley.daimi.aau.dk>; from "poe@daimi.aau.dk" at Feb 6, 92 4:19 pm +X-Mailer: ELM [version 2.3 PL4] + +>> If we could ignore our past, something like: +>> {/,/multiuser,/multiuser/package}{/executable,/data}{,/site,/local} +>> might be nicer still, but I can't pretend to believe something that +>> idealistic would gain much acceptance. +>Ideal, hmmmph. +:-) +Isn't that just what I'd said..? + +It's a bit over-different, but isn't the idea to separate the +code from the data? + +>> Is there a workable alternative to #! ? It's valuable, but it's +>> a *hack*. Someday, someone should implement a #$ that scans a (optionally +>> intrascript specified) path for the proper interpreter. Or perhaps, it +>> should be incorporated into the file system, as is being done with ACL's... +>> It might make sense to tackle both at the same time, with the addition of +>> an abstraction for "whatever's associated with this file" for tar's sake. +>Ugh! #! must only accept an absolute path for the interpreter, or you open +>a can of worms, securitywise. +Well... + +I wasn't all that serious about the change, though it's still something +I'd like to see. + +I'm not eager to start changing all my scripts from starting with +#!/usr/local/bin/bash to wherever bash starts going. But I'd rather +not see bash stay in /usr/local/bin forever, either. + +I'll end up changing it anyway. What I'd like to see, is provision +made for avoiding the same thing happening again, when some other +wonderful new interpreter gains acceptance. + +I fully acknowledge the abundance of kernel's that are stuck with 32 +bytes, due to the a.out stuff. It'll be a *long* time before any +benefit *might* be reaped. That doesn't mean we can't start speculating +about solutions now... + +Actually, maybe such a change should go in the shell, at least until +people stop using kernels provided by people who can't share. :-) + +The point of including the search path *within* the script, of course, +was to address precisely the security problem you raised, while still +providing a bit more flexibility. + +>> scripts. They should be deprecated, IMO. I'd actually be pretty +>> happy to see a distributed system with present, but empty, /usr/bin +>> and /usr/lib. +> +>I don't really see anything wrong with /usr/lib and /usr/bin. +I suppose there's no getting away from them. + +I'm less than completely happy with them, because they give a priviledged +status to certain programs. + +Consider: + +"Hm. I'm running gcc 1.40. I'd like to run gcc 2.0 now that it's out. +I've got gcc-related stuff in /usr/lib and /usr/bin Hm. gcc 2.0 wants +to go there *too*, and some of the names conflict, some don't. Well, +I guess I'll just back up {my system|those directories}, figure out +which files are used by gcc 1.40 *only*, and copy in the files for +2.0" + +That's good enough, as long it's not followed by: + +"Gee, gcc 2.0 isn't quite stable enough yet. But /usr/lib has changed in +more ways than just updating the compiler... Now I have to sort out what's +changed, and what hasn't... I'll want to hack up a shell script to figure +out what to keep, based on the dates, *excluding* the list of gcc 1.40 +files, which I can pick out of the distribution...." + +Or worse still: + +"Gee, gcc 2.0 is great... but this program requires gcc 1.40 to compile... +(Viz X windows or something) I guess I'll restore 1.40 temporarily, +compile, and put gcc 2.0 back..." + +Sure, it doesn't happen that often. But it's a headache when it does. +It's the avoidable headaches that I personally find the most annoying. +(Essentialy complexity I can live with, and even appreciate. Accidental +complexity, I find dehumanizing) + +I'd much prefer to be able to leave both on the system at various times, +and change environment variables to indicate which I want to use for a +given compilation. I'd probably leave only one on the system, most +of the time, but for those special cases... + +>> Termcap could be an app. Terminfo could be an app. gcc +>> could be an app, to make room for any other compilers that may be +>> coming. Shell-of-the-month's that aren't trusted enough for system +>> scripts, could be apps. The idea is that no piece of software is really +>> central to the system's existence. Ok, init and /bin/sh probably +>> should, though the sh is arguable. +> +>Does this mean that termcap and terminfo should be programs (applications? :-) +>or shuld they just reside in /usr/app +They'd just reside there, selbstverstandlich. + +"/usr/package", or an abbreviation thereof, might be preferable. + +>> Ideally, /,/bin,/etc, /lib, and /dev could be copied to a +>> (moderately sized) floppy filesystem, to get another system running +>> enough to de-tar an entire distribution from diskettes/tapes/cd-roms/ +>> network, and edit some config files, or invoke some simplistic +>> installation scripts/binaries. +>Good idea. +'tanks. + +>> In fact, a really nicely polished system might have two +>> password files: one for single user mode, on root, and one for multiuser, +>> on /usr somewhere, maybe /usr/etc. I'm less than happy about the +>> number of systems I've seen, that had /etc/passwd (and attendant +>> databases), outgrow their root partition. Putting just logins +>> for root, system accounts, and sysadmins in /etc/passwd (perhaps only +>> these would be allowed to log in on the console), and the bulk of +>> users in /usr/etc/passwd, would be kind of nice. +>Never heard of YP^H^H NIS? +Shrug. My Master's work has been replicating the passwd map, in a more +secure manner... + +It was an offhanded idea, but it's not too far from what I've done +in my MS stuff - the root partition on our machines here are just too +small our password databases. I've put an /etc/passwd-formatted file +at /usr/local/etc on our systems, and allow remote getpwnam's against +it, but not the /etc/passwd database itself. + +>> S. Egdorf has mentioned that much of the reason for UNIX's +>> lack of acceptance, is its lack of shrink-wrapped software. I support +>> his conclusion (that /site in some form, make sense, though it +>> could be replaced fully or in part, but /usr/app), but not his +>> reasoning... IMO, this is technically, and politically (I'll not get +>> started again...) a reason for UNIX's resilience, as well. +>> The fact that we don't have something as constrictive as +>> the BIOS hampering UNIX's growth, is in part a strength. POSIX +>> is testament to the flexibility, and viability, of a Better Way. +>Does anyone really think we will ever have shrik-wrapped apps. for linux?? +Well... + +Linux' doing a lot of the UNIX API already, you know? If UNIX gets +shrink-wrap going, it might be worth looking into for linux, in +*whatever* form. + +>I view linux as a hackers system, where we can have source for everything, and +>not have to rely on shrinkwrapped binaries-only packages. +I must admit, I like the extra flexibility of packages that come in source +form. I believe that's why UNIX is out-living MS-DOS, despite predating +MS-DOS. + +What I'm not crazy about, is the repetitive mapping of index to strchr and +such. I'd be perfectly happy to grab a copy of the latest raytracer off +the net, and not have to diddle any configuration parameters... + +>On another note, beware of the tendency to make linux an "design by commitee" +>system. I belive that linux is as good as it is, because it was designed and +>implemented by one man (Linus). This doesn't mean that we should stop making +>contributions and extensions, as Linus can't do everything for us. +> +>Trying to forge standards at this early stage seems a bit futile to me, +>time will tell where linux goes.... (This will probably make my mailbox +>bloat with flames, Oh well..) +Ah! Politics! :-) + +I don't see this as a flame; you might: I'd rather see linux guided by +a group of people who can make suggestions, without getting crazy if +something gets voted down, than a more usual committee, or even just +letting it take its course. + +Given Linus' discussion with Tannenbaum on comp.os.minix, I'd he's +pretty realistic about the fact that lots of people will have lots +of different desires, with regard to Linux' future. + +In fact, I'd say his choice of copyright mandates it. + +> - Peter. + +- Dan + + +From linux Sun Feb 9 20:18:11 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <10616-0@banjo.concert.net>; Sun, 9 Feb 1992 20:17:21 -0500 +Received: from ux1.isu.edu ([134.50.254.5]) + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA11262; + Sun, 9 Feb 92 20:17:17 -0500 +Message-Id: <9202100117.AA11262@jazz.concert.net> +Received: by ux1.isu.edu (16.6/16.2) id AA00967; Sun, 9 Feb 92 18:22:00 -0700 +Date: Sun, 9 Feb 92 18:22:00 -0700 +From: Dan Simmons +To: linux-standards@concert.net +Subject: installing & uninstalling packages + + +Just a thought... Give me your reactions. + +I know that this would be introducing something totally non-standard into +linux, but it seems like it might be worth doing, and I think it could be +implemented with complete or nearly complete backward compatibility. + +Here it is: Add another "owner" field to each file. This field will not be +used for security at all but for additional flexibility in specifying groups +of files. So you would have, owner, group, and something we might call +"package". When you install a package on the system, you would write all the +files to disk with a unique package number. That is, the install program would +query the system for a new package number and then write that along with a +package name into some file kind of like /etc/passwd which maps the numbers to +the packages. Then you could either implement some separate commands or new +switches on old commands which would allow you to list/remove, etc. Any files +tagged with a particular package number. + +I can think of several problems with this idea, but I can also see many +advantages. There are lots of people complaining about the file system +structure and the trouble of identifying which files in /usr/lib belong to +gcc-1.40 and which to gcc-2.0, and this might be a solution... + +So, there it is. What do you think? + +Daniel Simmons dsimmons@cs.cornell.edu, simmdan@ux1.isu.edu +------------------------------------------------------------------------- +For the Lord of hosts has planned, and who can frustrate it? And as for +His stretched-out hand, who can turn it back? -- Isaiah 14:27 + +From linux Tue Feb 11 08:38:35 1992 +Return-Path: +Subject: Draft 2 of FILE SYSTEM STRUCTURE +To: linux-standards@concert.net +Date: Tue, 11 Feb 92 8:37:23 EST +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@concert.net + +Well, thanks to everyone for their input on Draft 1. I have marked all the +changes between Draft 1 and Draft 2 with vertical bars (|) in column 1. + +Please send comments. + +============== +The following is being submitted by Alan Clegg [abc@concert.net] as the +proposed standard for directory file structure under Linux. + +REVISION TWO. + +Complete implementation of this file structure is completely voluntary, +and will not be enforced, but will be recommended. This specification +is released as guidelines for people porting and writing software for +the Linux Operating System to allow easy software installation, upgrade, and +tailoring on already installed systems. + +Root Directory: + + Files: + {none defined by spec} + + Directories: +| bin dev etc home lib mnt usr + + Rationale: + The root directory should not be cluttered with files or + directories, and should contain no user programs. + +/bin Directory: + + Files: + sh init mount umount dd cat ls fsck {and as needed} + + Directories: + {none defined by spec} + + Rationale: + The /bin directory should contain programs that are vital + to the restoration of other file systems in the case of + a corrupting crash. No executable in /bin should require + any other file system to be mounted to execute correctly. + +/dev Directory: + + Files: + {device files} + + Directories: + {none define by spec} + + Rationale: +| Standard UNIX device files. This directory should contain +| device entries for all devices that are supported in the +| standard kernel, even if the hardware device does not exist +| on the system. Note that the distribution will have all +| device files, but they may be removed by the user upon +| system installation. + +/etc Directory: + + Files: + mtab passwd rc ttytab {and as needed} + + Directories: + {none defined by spec} + + Rationale: + Standard location of files required during system boot. Files + in this directory are usually system specific. Most will + require human intervention during system upgrade. + +|/home Directory: +| +| Files: +| NONE +| +| Directories: +| {one per user excepting root} +| +| Rationale: +| Standard location of users home directories. Will most likely +| be a mounted file system once the system is up. root's home +| directory should be /. + +/lib Directory: + + Files: + {libraries required for system initialization} + + Directories: + {none defined by spec} + + Rationale: + To keep the size of the root partition small (if separate from + /usr), the files in this directory should only be ones required + by files in the root partition. + +/mnt Directory: + + Files: + NONE + + Directories: + NONE + + Rationale: + Standard mount point for external (transient) file systems. + Must be available for sub-system installation. Should remain + as an empty directory. + +/tmp Directory: + + Files: + NONE + + Directories: + NONE + + Rationale: + Temporary file space available for general program use. May + become a mounted partition upon system boot. [Minimum size?] + +/usr Directory: + + Files: + {none defined by spec} + + Directories: + adm bin spool local lib etc man include src tmp + + Rationale: + /usr is the mount point for the second major (after root) + hierarchy of file structure and is discussed in the next + section. + +/usr/adm Directory: + + Files: + {none defined in spec} + + Directories: + {none defined in spec} + + Rationale: + Location of log files and accounting information. + +/usr/bin Directory: + + Files: + {all executable files from standard distribution not contined + in /bin} + + Directories: + {none defined in spec} + + Rationale: + contains 'drop-in' executables that are considered to be + standard to the UNIX system. These files should NOT be + Linux specific, but should have the same function as their + UNIX equivalents. + +/usr/etc Directory: + + Files: + {none defined in spec} + + Directories: + {none defined in spec} + + Rationale: + contains configuration files for any files in /usr/bin. helps + to keep /etc clean and small. + +/usr/spool Directory: + + Files: + {none defined in spec} + + Directories: + uucp mail + + Rationale: + containes spool files for mail, printing, uucp transfer, etc. + May be a mount point for another volume. + +/usr/local Directory: + + Files: +| NONE + + Directories: + bin lib etc man src + + Rationale: + contains files local to the specific system. will not be + modified by upgrade process. + +/usr/lib Directory: + + Files: + libc.a crt0.s {and as needed} + + Directories: + {none defined in spec} + + Rationale: + location for library files required for multi-user system + operation. This is the directory where program libraries + should reside. + +/usr/man Directory: + + Files: + NONE + + Directories: + man1 man2 man3 man4 man5 man6 man7 man8 + + Rationale: + Contains manual pages for programs that are standard with + Linux. + +/usr/include Directory: + + Files: + {programmers include files} + + Directories: + {as needed} + + Rationale: + Standard place for system include files. + +/usr/src Directory: + + Files: + NONE + + Directories: +| bin lib linux usr.bin usr.lib + + Rationale: + Contains source code for all applications in the release. + /usr/src/linux contains directories required for kernel builds. + +/usr/tmp Directory: + + Files: + NONE + + + Directories: + NONE + + Rationale: + Used as additional scratch space for programs. If /tmp is + a mounted file system, /usr/tmp may be a symbolic link to + /tmp. + +==============REMOVED============== +/usr/linux Directory: + + Rationale for removal: + No clean definition of 'linux specific'. All binaries, + libraries, and etc will reside below / and /usr. + +/usr/users Directory: + + Rationale for removal: + Moved to /home. +==============REMOVED============== + +Please feel free to comment on these ideas, and let me know what you think. +============== + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux Tue Feb 11 09:08:41 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <19034-0@banjo.concert.net>; Tue, 11 Feb 1992 09:07:49 -0500 +Received: from sumax.seattleu.edu + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA24965; + Tue, 11 Feb 92 09:07:45 -0500 +Received: by sumax.seattleu.edu id AA24326 (5.65a/IDA-1.4.2 + for linux-standards@concert.net); Tue, 11 Feb 92 06:10:22 -0800 +Date: Tue, 11 Feb 92 06:10:22 -0800 +From: Chuck Boyer +Message-Id: <9202111410.AA24326@sumax.seattleu.edu> +To: abc@concert.net, linux-standards@concert.net +Subject: Re: Draft 2 of FILE SYSTEM STRUCTURE + +Fine, vote one for 'yes'. Make it so. Then, when someone distributes +something that uses dirs differently they can list such in the Readme +file for compilation. +chuck + +From linux Tue Feb 11 09:29:32 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <184-0@banjo.concert.net>; Tue, 11 Feb 1992 09:28:04 -0500 +Received: from daimi.aau.dk by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA25277; Tue, 11 Feb 92 09:27:55 -0500 +Received: from bentley.daimi.aau.dk by daimi.aau.dk + with SMTP (5.61++/IDA-1.2.8) id AA09800; + Tue, 11 Feb 92 15:26:26 +0100 +Received: by bentley.daimi.aau.dk (5.64/1.34) id AA06465; + Tue, 11 Feb 92 15:26:17 +0100 +Date: Tue, 11 Feb 92 15:26:17 +0100 +From: tthorn@daimi.aau.dk +Message-Id: <9202111426.AA06465@bentley.daimi.aau.dk> +To: abc@concert.net +Cc: linux-standards@concert.net +In-Reply-To: Alan B Clegg's message of Tue, 11 Feb 92 8:37:23 EST <9202111337.AA08398@daimi.aau.dk> +Subject: Draft 2 of FILE SYSTEM STRUCTURE + +YES! It's just right. Only remark: aren't we missing cat[1-8] in /usr/man? + +/Tommy + +From linux Tue Feb 11 16:59:56 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <3434-0@banjo.concert.net>; Tue, 11 Feb 1992 16:59:23 -0500 +Received: from stolaf.edu (nic.stolaf.edu) + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA03712; + Tue, 11 Feb 92 16:59:19 -0500 +Received: from loki2.cs.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA14534; + Tue, 11 Feb 92 15:59:09 CST +Date: Tue, 11 Feb 92 15:59:09 CST +From: johnsonm@stolaf.edu (Michael K. Johnson) +Message-Id: <9202112159.AA14534@stolaf.edu> +Received: by loki2.cs.stolaf.edu (4.1/SMI-4.1) id AA04011; + Tue, 11 Feb 92 15:59:09 CST +Cc: linux-standards@concert.net +In-Reply-To: Alan B Clegg's message of Tue, 11 Feb 92 8:37:23 EST <9202111342.AA00548@stolaf.edu> +Subject: Draft 2 of FILE SYSTEM STRUCTURE + +I vote yes on the file system structure as proposed. + +I don't particularily like /usr/src/usr.{bin,lib} (I would prefer +/usr/src/usr/{bin,lib}, but I didn't get around to bringing it up in +our discussion, so I'll be quiet :-) + +I also don't like /usr/tmp & /tmp as separate directories at all. I +think that they should be links, one way or the other, preferably to a +fs other than root. + +I agree with both removals. + +michaelkjohnson +johnsonm@stolaf.edu +I don't do .sig's. + +From linux Tue Feb 11 18:37:33 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <3699-0@banjo.concert.net>; Tue, 11 Feb 1992 18:36:32 -0500 +Received: from tsx-11.MIT.EDU by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA04493; Tue, 11 Feb 92 18:36:30 -0500 +Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA01539; + Tue, 11 Feb 92 18:36:23 -0500 +Date: Tue, 11 Feb 92 18:36:23 -0500 +From: tytso@ATHENA.MIT.edu (Theodore Ts'o) +Message-Id: <9202112336.AA01539@tsx-11.MIT.EDU> +To: johnsonm@stolaf.edu +Cc: linux-standards@concert.net +In-Reply-To: Michael K. Johnson's message of Tue, 11 Feb 92 15:59:09 CST, <9202112159.AA14534@stolaf.edu> +Subject: Re: Draft 2 of FILE SYSTEM STRUCTURE +Reply-To: tytso@athena.mit.edu +Address: 1 Amherst St., Cambridge, MA 02139 +Phone: (617) 253-8091 + + Date: Tue, 11 Feb 92 15:59:09 CST + From: johnsonm@stolaf.edu (Michael K. Johnson) + + I also don't like /usr/tmp & /tmp as separate directories at all. I + think that they should be links, one way or the other, preferably to a + fs other than root. + +No, I think they need to be different. The big difference is that /tmp +gets cleared on reboot, and /usr/tmp does not. So for example, if your +machine crashes while you are working, emacs autosave files (which in +/usr/tmp) don't get deleted. However if you are using a networked +authentication system, such as Kerberos, you would want the +cryptographic information proving your identity to be stored in /tmp, +which would be deleted upon reboot. Other temporary files which are +used by processes (like gcc) also put their files in /tmp, and they also +should be deleted upon reboot. + + +All in all, I like "Draft 2 of the FILE SYSTEM STRUCTURE". My only one +nit is with /homes, which I think is a bad idea. I would much rather +prefer /usr/homes, so that if you have an extra partition, you can mount +it over /usr/homes, but if you don't have an extra partition to spare +(and you still want the root to be small), you can leave it in the /usr +partition. By putting that directory in /homes, you remove that choice. + +It's not a big deal though. I will probably deal with this problem by +installing a sym link from /homes to /usr/homes. Where home directories +"really" are isn't very important anyway, since no program should be +depending on their location. + + - Ted + +From linux Wed Feb 12 11:05:20 1992 +Return-Path: +Subject: Draft moved to Final +To: linux-standards@concert.net +Date: Wed, 12 Feb 92 11:04:46 EST +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@concert.net + +Well, with everyone not responding taken as a "HOORAY, IT LOOKS *GREAT*", +we have 98% agreement with the Draft File System document. + +I suggest that we move it from Draft into Final standard, and send it to +linux-activists and alt.os.linux. + +Any seconds? +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux Wed Feb 12 11:45:18 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <7835-0@banjo.concert.net>; Wed, 12 Feb 1992 11:44:16 -0500 +Received: from stolaf.edu (nic.stolaf.edu) + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA10421; + Wed, 12 Feb 92 11:44:09 -0500 +Received: from amcl11.math.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA05685; + Wed, 12 Feb 92 10:44:01 CST +Date: Wed, 12 Feb 92 10:44:01 CST +From: johnsonm@stolaf.edu (Michael K. Johnson) +Message-Id: <9202121644.AA05685@stolaf.edu> +Received: by amcl11.math.stolaf.edu (4.1/SMI-4.1) id AA04828; + Wed, 12 Feb 92 10:44:00 CST +To: linux-standards@concert.net +In-Reply-To: Alan B Clegg's message of Wed, 12 Feb 92 11:04:46 EST <9202121610.AA05214@stolaf.edu> +Subject: Draft moved to Final + + Well, with everyone not responding taken as a "HOORAY, IT LOOKS *GREAT*", + we have 98% agreement with the Draft File System document. + + I suggest that we move it from Draft into Final standard, and send it to + linux-activists and alt.os.linux. + + Any seconds? + +I second the motion :-) + +michaelkjohnson +johnsonm@stolaf.edu +I don't do .sig's. + + +From linux Wed Feb 12 12:36:42 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <8613-0@banjo.concert.net>; Wed, 12 Feb 1992 12:35:30 -0500 +Received: from sumax.seattleu.edu + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA10825; + Wed, 12 Feb 92 12:35:26 -0500 +Received: by sumax.seattleu.edu id AA15117 (5.65a/IDA-1.4.2 + for linux-standards@concert.net); Wed, 12 Feb 92 09:38:03 -0800 +Date: Wed, 12 Feb 92 09:38:03 -0800 +From: Chuck Boyer +Message-Id: <9202121738.AA15117@sumax.seattleu.edu> +To: abc@concert.net, linux-standards@concert.net +Subject: Re: Draft moved to Final + +Make it so. + +From linux Wed Feb 12 13:03:49 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <8822-0@banjo.concert.net>; Wed, 12 Feb 1992 13:02:57 -0500 +Received: from sun2.nsfnet-relay.ac.uk + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA11255; + Wed, 12 Feb 92 13:02:36 -0500 +Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk + via JANET with NIFTP id <10909-0@sun2.nsfnet-relay.ac.uk>; + Wed, 12 Feb 1992 13:25:00 +0000 +Message-Id: <12 Feb 92 12:10:57 GMT ZLSIIAL@UK.AC.MCC.CMS> +Date: Wed, 12 Feb 92 12:10:57 GMT +From: LeBlanc@manchester-computing-centre.ac.uk +Myname: A. V. Le Blanc +To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@concert.net> +Subject: Comments on Draft 2 + + +1) I am a little unhappy about having init in /bin, since no + user -- not even root -- needs to access it. Should this + be in lib? + +2) I do not think root's home directory should be in /, since + this means that / tends to accumulate .exrc, .profile, .bashrc, + .kermrc, etc. Also there are utilities that write files in + your home directory; these should not write to /. + +3) What goes in /lib? The draft says 'libraries required for + system initialisation'. I presume this is either shared + libraries (in which case libc.a belongs here, not in /usr/lib) + or libraries needed to reconfigure the kernel (in which case, + /lib does not seem as approproate as /usr/etc or /etc). + +4) The draft says that /usr/lib should contain crt0.s. Presumably + this is an error for crt0.o. + +Generally I think the draft is good, providing clear reasons for +simple choices. + + A. V. Le Blanc + University of Manchester + LeBlanc@mcc.ac.uk + +From linux Wed Feb 12 17:33:19 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <11556-0@banjo.concert.net>; Wed, 12 Feb 1992 17:32:46 -0500 +Received: from stolaf.edu (nic.stolaf.edu) + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA19615; + Wed, 12 Feb 92 17:32:41 -0500 +Received: from loki6.cs.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA06770; + Wed, 12 Feb 92 16:32:32 CST +Date: Wed, 12 Feb 92 16:32:32 CST +From: johnsonm@stolaf.edu (Michael K. Johnson) +Message-Id: <9202122232.AA06770@stolaf.edu> +Received: by loki6.cs.stolaf.edu (4.1/SMI-4.1) id AA01914; + Wed, 12 Feb 92 16:32:26 CST +To: linux-standards@concert.net +In-Reply-To: LeBlanc@manchester-computing-centre.ac.uk's message of Wed, 12 Feb 92 12:10:57 GMT <12 Feb 92 12:10:57 GMT ZLSIIAL@UK.AC.MCC.CMS> +Subject: Comments on Draft 2 + + Date: Wed, 12 Feb 92 12:10:57 GMT + From: LeBlanc@manchester-computing-centre.ac.uk + Myname: A. V. Le Blanc + + + 1) I am a little unhappy about having init in /bin, since no + user -- not even root -- needs to access it. Should this + be in lib? + +I don't think that we want any executables in /lib. if you don't want +it in bin, you could put it in /etc, but we are trying to keep +executables out of /etc in the standard, if I recall corectly. So +/bin makes sense to me. And it doesn't cost _that_ much search time, +and when we get ffs and other advanced fs's that do non-linear +searches, it will essentially be a moot point. And it shouldn't be +that much longer till ffs, so let's design around ffs not the v7 fs. + + 2) I do not think root's home directory should be in /, since + this means that / tends to accumulate .exrc, .profile, .bashrc, + .kermrc, etc. Also there are utilities that write files in + your home directory; these should not write to /. + +Correct me if I am wrong (not that I am worried that people wouldn't... +:-) but root, the user, should not have such files. once we have +init, we want to spend as little time logged in as root as possible, +and then usually su'd to root. + + 3) What goes in /lib? The draft says 'libraries required for + system initialisation'. I presume this is either shared + libraries (in which case libc.a belongs here, not in /usr/lib) + or libraries needed to reconfigure the kernel (in which case, + /lib does not seem as approproate as /usr/etc or /etc). + +Good point, I think. Unless we staticly link everything in /bin, we +need the shared libes in the root fs. ooh, yuk. Anyone have a better +solution? I'd hate to go with staticly linked /sbin and dynamically +linked /bin... + +Of course, I am probably missing something entirely... + + +michaelkjohnson +johnsonm@stolaf.edu +Look, Ma, no .sig! + +From linux Thu Feb 13 04:01:53 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <13383-0@banjo.concert.net>; Thu, 13 Feb 1992 04:00:57 -0500 +Received: from sun2.nsfnet-relay.ac.uk + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA21143; + Thu, 13 Feb 92 04:00:51 -0500 +Message-Id: <9202130900.AA21143@jazz.concert.net> +Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP + id <5478-0@sun2.nsfnet-relay.ac.uk>; Thu, 13 Feb 1992 08:33:17 +0000 +Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa14210; + 13 Feb 92 8:41 GMT +Date: Thu, 13 Feb 92 08:38:47 +0000 +From: db1@ukc.ac.uk +To: linux-standards@concert.net +Subject: Root home in / + +Root home is usually in / since any other directory may be mounted +Therefore, If you want to do admin with a broken disk or handle +your disks in Single user you need root to be in / + +BTW. You can use su from ordinary user if you want to be root and +stiil retain the current home +( su - ) Changes HOME also, su alone leave the current. + +Damiano + +From linux Thu Feb 13 04:25:31 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <13475-0@banjo.concert.net>; Thu, 13 Feb 1992 04:24:26 -0500 +Received: from ebr.eb.ele.tue.nl by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA21176; Thu, 13 Feb 92 04:24:21 -0500 +Received: by ebr.eb.ele.tue.nl (5.65b/1.53) id AA08950; + Thu, 13 Feb 92 10:23:32 +0100 +Date: Thu, 13 Feb 92 10:23:32 +0100 +From: volf@eb.ele.tue.nl (Frank Volf) +Message-Id: <9202130923.AA08950@ebr.eb.ele.tue.nl> +To: johnsonm@stolaf.edu, linux-standards@concert.net +Subject: Re: Comments on Draft 2 + + +Hi, + +You johnsonm@stolaf.edu (Michael K. Johnson) wrote: + +> 1) I am a little unhappy about having init in /bin, since no +> user -- not even root -- needs to access it. Should this +> be in lib? +> +>I don't think that we want any executables in /lib. if you don't want +>it in bin, you could put it in /etc, but we are trying to keep +>executables out of /etc in the standard, if I recall corectly. So + ^^^^^^^^^^^ + +Why??? I always thought most of the man (8) commands should be in +/etc (or /usr/etc). At least at our site it does. +I think it is not a good idea to have any commands in /bin which +are not intended for ordinary users. These commands include +mknod, mkswap, fsck, mount, umount and other stuff we don't have yet +(reboot, lpc for example). + +I think that all those commands intended for system administration (and +not useful for the other users) should go into /etc or /usr/etc. Ordinary +users should not have /etc in their search path (although we can't prevent +them from doing so). Root should have /etc in the very beginning of its +search path. + +Init should not be in /bin. It is not an executable in the sense it can +be run by any user (including root). /etc/init would be a good idea (at +our side it is). If /etc/init is a very big problem (which isn't I think) +it should go to /lib (there are executables in /usr/lib (for example atrun, +cpp etc.) so why not in /lib??? (although the best place is /etc) + + Best regards, Frank + +------------------------------------------------------------------------ +- Frank Volf INTERNET : volf@eb.ele.tue.nl - +- Eindhoven University of Technology - +- Digital Systems Group, Room EH10.16 - +- P.O. 513, - +- 5600 MB Eindhoven, The Netherlands - +------------------------------------------------------------------------ + +From linux Thu Feb 13 09:14:58 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <14484-0@banjo.concert.net>; Thu, 13 Feb 1992 09:13:35 -0500 +Received: from sage.cc.purdue.edu + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA22955; + Thu, 13 Feb 92 09:13:33 -0500 +Received: by sage.cc.purdue.edu (5.61/Purdue_CC) id AA02565; + Thu, 13 Feb 92 09:13:25 -0500 +From: asg@sage.cc.purdue.edu (The Grand Master) +Message-Id: <9202131413.AA02565@sage.cc.purdue.edu> +Subject: Re: Comments on Draft 2 +To: johnsonm@stolaf.edu (Michael K. Johnson) +Date: Thu, 13 Feb 92 9:13:23 EST +Cc: linux-standards@concert.net +In-Reply-To: <9202122232.AA06770@stolaf.edu>; from "Michael K. Johnson" at Feb 12, 92 4:32 pm +Needs: Your attention +Organization: Fraternal Order of Red-haired Milkmaids + +In the unforgettable words of Michael K. Johnson: +-> +-> Date: Wed, 12 Feb 92 12:10:57 GMT +-> From: LeBlanc@manchester-computing-centre.ac.uk +-> Myname: A. V. Le Blanc +-> +->I don't think that we want any executables in /lib. if you don't want +->it in bin, you could put it in /etc, but we are trying to keep +->executables out of /etc in the standard, if I recall corectly. So +->/bin makes sense to me. And it doesn't cost _that_ much search time, +->and when we get ffs and other advanced fs's that do non-linear +->searches, it will essentially be a moot point. And it shouldn't be +->that much longer till ffs, so let's design around ffs not the v7 fs. + +Well....... + I do not understand this fascination with keeping executables out +of etc. It is normal, traditional UNIX convention for mount, umount, +mknod, mkfs, shutdown, etc to be in /etc (no pun intended). I think +it should be done that way. +-> +-> 2) I do not think root's home directory should be in /, since +-> this means that / tends to accumulate .exrc, .profile, .bashrc, +-> .kermrc, etc. Also there are utilities that write files in +-> your home directory; these should not write to /. +-> +->Correct me if I am wrong (not that I am worried that people wouldn't... +->:-) but root, the user, should not have such files. once we have +->init, we want to spend as little time logged in as root as possible, +->and then usually su'd to root. + +root still needs .profile, .exrc, and .bashrc. When you log in as root +(those seldom occasions) you want your environment set up. And when you +su to root, you want .bashrc to set some things up for you (maybe an +alias like alias rm='rm -i'). In either case, you want .exrc (or .emacs +if you prefer emacs) so that when root edits files, your normal (or +some special root) macros are available. +-> + + Bruce + +-- +Disclaimer: The aka "The Grand Master" Courtesy of Bruce Varney + is due to an inside joke among aka -> The Grand Master + myself and some old friends - asg@sage.cc.purdue.edu + so please don't take offense PUCC + +From linux Thu Feb 13 11:43:05 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <15542-0@banjo.concert.net>; Thu, 13 Feb 1992 11:42:30 -0500 +Received: from engr.uark.edu by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA25141; Thu, 13 Feb 92 11:42:28 -0500 +Received: by engr.uark.edu (/\==/\ Smail3.1.25.1 #25.3) + id ; Thu, 13 Feb 92 10:42 CST +Message-Id: +Date: Thu, 13 Feb 92 10:42 CST +From: dws@engr.uark.edu (David W. Summers) +To: linux-standards@concert.net +Subject: Re: Comments on Draft 2 + +I've been watching the debate about where to put Admin files and executables. + +What I would like is to have the executables either in /etc/bin or /usr/etc +and the admin files themselves in /etc. + +Someone mentioned that they "didn't understand this fascination with keeping +executables out of etc." + +Well, I would like to keep them out, because sometimes it is confusing +(even to Sys. Admin. types like me! :-) whether or not a file (just by looking +at the file name) is supposed to be an executable or a data file). I know, +you can "ls -l" and see, but I like the separation of data files and executables +like we normally have in other directories. + +I agree there should probably not be any executables in /lib or /usr/lib, but +then again, we need somewhere to put that stuff. I think that many (most?) +times things like that should go in /etc/bin or /usr/etc. + +As to where root's home should go, how about "/root" ???? + + - David Summers + +From linux Thu Feb 13 13:14:04 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <15990-0@banjo.concert.net>; Thu, 13 Feb 1992 13:13:28 -0500 +Received: from sage.cc.purdue.edu + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA26925; + Thu, 13 Feb 92 13:13:25 -0500 +Received: by sage.cc.purdue.edu (5.61/Purdue_CC) id AA03003; + Thu, 13 Feb 92 13:13:16 -0500 +From: asg@sage.cc.purdue.edu (The Grand Master) +Message-Id: <9202131813.AA03003@sage.cc.purdue.edu> +Subject: Re: Comments on Draft 2 +To: dws@engr.uark.edu (David W. Summers) +Date: Thu, 13 Feb 92 13:13:15 EST +Cc: linux-standards@concert.net +In-Reply-To: ; from "David W. Summers" at Feb 13, 92 10:42 am +Needs: Your attention +Organization: Fraternal Order of Red-haired Milkmaids + +In the unforgettable words of David W. Summers: +-> +->I've been watching the debate about where to put Admin files and executables. +-> +->What I would like is to have the executables either in /etc/bin or /usr/etc +->and the admin files themselves in /etc. +-> +->Someone mentioned that they "didn't understand this fascination with keeping +->executables out of etc." +-> +->Well, I would like to keep them out, because sometimes it is confusing +->(even to Sys. Admin. types like me! :-) whether or not a file (just by looking +->at the file name) is supposed to be an executable or a data file). I know, +->you can "ls -l" and see, but I like the separation of data files and executables +->like we normally have in other directories. + +Try "ls -F". Files in /etc are ones that are needed for basic system +administration, etc. This is normal, and there is no reason to change it. +Do you yet another directory for shell scripts? They are different from +binaries, and yet different from data files as well. Maybe we +should have another directory that just holds passwd and group. They +are different from utmp or mtab. You can carry division too far (which +you are doing). I am sure there are shell scripts (or even c-programs) +that have /etc/{some normal system admin command} in them. Do *YOU* want +to have to convert all those?? +-> +->I agree there should probably not be any executables in /lib or /usr/lib, but +->then again, we need somewhere to put that stuff. I think that many (most?) +->times things like that should go in /etc/bin or /usr/etc. + +THERE ARE EXECUTABLES IN /usr/lib. WHAT DO YOU THING cpp IS??????? +-> +->As to where root's home should go, how about "/root" ???? + +No. / is apropriate. That is the whole purpose of calling the user root. + + + Bruce +-- +Disclaimer: The aka "The Grand Master" Courtesy of Bruce Varney + is due to an inside joke among aka -> The Grand Master + myself and some old friends - asg@sage.cc.purdue.edu + so please don't take offense PUCC + +From linux Thu Feb 13 14:25:45 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <17103-0@banjo.concert.net>; Thu, 13 Feb 1992 14:24:26 -0500 +Received: from engr.uark.edu by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA28236; Thu, 13 Feb 92 14:24:22 -0500 +Received: by engr.uark.edu (/\==/\ Smail3.1.25.1 #25.3) + id ; Thu, 13 Feb 92 13:25 CST +Message-Id: +Date: Thu, 13 Feb 92 13:25 CST +From: dws@engr.uark.edu (David W. Summers) +To: linux-standards@concert.net +Subject: Standards Directories + +Linuxers: + +Also, in the BSD distribution, I noticed some /usr/include/path.h files. + +If we would define common (standardized) '#define's, then we could just +reference those defines in all the new programs and they would go where +YOU want them! + +Comments? Is this already being done? + + - David Summers + +From linux Thu Feb 13 15:56:24 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <598-0@banjo.concert.net>; Thu, 13 Feb 1992 15:55:35 -0500 +Received: from Kodak.COM by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA29651; Thu, 13 Feb 92 15:55:30 -0500 +Received: from kodak.kodak.com by Kodak.COM (5.61+/2.1-Eastman Kodak) + id AA06159; Thu, 13 Feb 92 15:54:33 -0500 +Reply-To: nobody@Kodak.com +Received: from sisd.kodak.com by kodak.Kodak.COM (4.1/SMI-4.1) id AA18837; + Thu, 13 Feb 92 15:55:08 EST +Received: from acorn.UUCP by sisd.kodak.com (4.1/SMI-4.x_sisd_main_v1) + id AA18048; Thu, 13 Feb 92 15:53:46 EST +Received: from flash.acorn by acorn (4.1/SMI-4.0) id AA09661; + Thu, 13 Feb 92 15:50:52 EST +Received: by flash.acorn (4.1/SMI-4.1) id AA15641; Thu, 13 Feb 92 15:50:50 EST +Date: Thu, 13 Feb 92 15:50:50 EST +From: obz@sisd.sisd.Kodak.com (Orest Zborowski) +Message-Id: <9202132050.AA15641@flash.acorn> +To: linux-standards@concert.net +Subject: standard directory hierarchy + +i have a few thoughts on this directory issue: + +1) linux is supposed to support posix - it does a pretty good job supporting + posix.1, the os interface layer. there is a posix.2 which describes a bunch + of utilities available from the shell. i'm not sure it has produced any + standards document, but i do believe i've read about its progress in + communications of the acm, and in ieee computer. this should be the + authority. + +2) following svr4 standards seems to be the logical next step. svr4 is truly + posix compliant and posix seems to lean heavily to sysv for certain things + like directory structure. bsd, especially sunos, is also moving towards + svr4. + +3) its true, certain applications have /lib/cpp burned into them and its gonna + be difficult to remove it. even things like the standards can't remove that + stain; you can move it (like sunos, which symlinks everything), but you can't + remove it. + +i think its a little naive to believe that we can come up with some special +directory hierarchy which is the be-all and end-all of structures, and then +we should change all these programs to conform. if you like, you can make +whatever changes you desire, like using symlinks to keep a partition readonly, +or shareable; changing the entry in /etc/passwd and make roots directory +/root, etc. for the standard distribution i would choose to make as few +changes from existing standards or existing implementations as possible. + +zorst +obz@sisd.kodak.com + +From linux Thu Feb 13 18:20:17 1992 +Return-Path: +Received: from nic.stolaf.edu by banjo.concert.net with SMTP (PP) + id <1467-0@banjo.concert.net>; Thu, 13 Feb 1992 18:19:30 -0500 +Received: from amcl3.math.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA02138; + Thu, 13 Feb 92 17:19:20 CST +Date: Thu, 13 Feb 92 17:19:20 CST +From: johnsonm@stolaf.edu (Michael K. Johnson) +Message-Id: <9202132319.AA02138@stolaf.edu> +Received: by amcl3.math.stolaf.edu (4.1/SMI-4.1) id AA01505; + Thu, 13 Feb 92 17:19:19 CST +To: linux-standards@banjo.concert.net +Subject: POSIX + +Does everyone know that the POSIX standards are available for ftp? + +they are at research.att.com in the posix directory. Instead +of arguing about what they say, we can go look. login netlib, +password ident. You will want to be aware that the whole thing is +several megs, but it is freely available. If you are insane enough to +want to print it out, it is over 1100 pages. + +You can get text or ps versions: I have been warned that the ps +versions (many megs) are not the best postscript, but I cannot verify +this, since I felt that the most useful thing would be the text +version. You also have the option of getting the whole thing in one +chunk or getting all the little pieces and only getting what you need. +This is facillitated by the availability of a table of contents. + +this is the file /netlib/posix/index:research.att.com + +-----8<----- + +This directory tree contains some working papers for POSIX committees +operating under the auspices of the IEEE. These are being made available +with the kind permission of both the IEEE and the working groups involved. +Suggestions or comments should be sent to Hal Jespersen, TCOS SEC Vice +Chair: hlj@posix.com. Information about the POSIX or IEEE standards +process can be obtained from Jim Isaak, TCOS SEC Chair: isaak@decvax.dec.com. + +Online access to these documents is an experimental procedure. Only a +small subset of documents will be immediately available, but the number +should increase over time. + +The directory structure is roughly: + + committee/draftnumber/file Draft documents + meeting/file Meeting announcements and agendas + minutes/file Meeting minutes + +Drafts are often available in both plain text and a page layout +language, most often PostScript. The following committees have drafts +available: + + p1003.2 + p1003.0 + p1003.2a + p1003.2b + +There is also a directory of interest to POSIX technical editors: + + teched + +-----8<----- + +You can look around from there. + +Have fun, and I hope that this helps. + +michaelkjohnson +johnsonm@stolaf.edu +I don't do .sig's. + +From linux Thu Feb 13 18:26:00 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <1514-0@banjo.concert.net>; Thu, 13 Feb 1992 18:25:28 -0500 +Received: from ncnoc.concert.net by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA01454; Thu, 13 Feb 92 18:25:26 -0500 +Received: from stolaf.edu (nic.stolaf.edu) + by ncnoc.concert.net (5.59/tas-concert/6-19-91) id AA10108; + Thu, 13 Feb 92 18:25:23 -0500 +Received: from amcl3.math.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA02222; + Thu, 13 Feb 92 17:24:01 CST +Date: Thu, 13 Feb 92 17:24:01 CST +From: johnsonm@stolaf.edu (Michael K. Johnson) +Message-Id: <9202132324.AA02222@stolaf.edu> +Received: by amcl3.math.stolaf.edu (4.1/SMI-4.1) id AA01514; + Thu, 13 Feb 92 17:24:01 CST +To: linux-standards@concert.net +In-Reply-To: Frank Volf's message of Thu, 13 Feb 92 10:23:32 +0100 <9202130923.AA08950@ebr.eb.ele.tue.nl> +Subject: Comments on Draft 2 + +I, johnsonm@stolaf.edu, said + >it in bin, you could put it in /etc, but we are trying to keep + >executables out of /etc in the standard, if I recall corectly. So + ^^^^^^^^^^^ +disengage brain, engage fingers.... BEEP BEEP BEEP wrong. thanks +for corrections... + +michaelkjohnson +johnsonm@stolaf.edu +I don't do .sig's. + +From linux Thu Feb 13 22:20:48 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <2333-0@banjo.concert.net>; Thu, 13 Feb 1992 22:20:10 -0500 +Received: from sumax.seattleu.edu + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA02013; + Thu, 13 Feb 92 22:20:07 -0500 +Received: by sumax.seattleu.edu id AA12305 (5.65a/IDA-1.4.2 + for linux-standards@concert.net); Thu, 13 Feb 92 19:22:36 -0800 +Date: Thu, 13 Feb 92 19:22:36 -0800 +From: Chuck Boyer +Message-Id: <9202140322.AA12305@sumax.seattleu.edu> +To: johnsonm@stolaf.edu, linux-standards@concert.net +Subject: Re: Comments on Draft 2 + +Well, it seems to me, that with 3 or 4 major 'basic' machines (SUN, PC +clone 386, 'old' unix users, 'new' unix users) that there should be +agreed upon by a vote which set of standards of a dir tree structure +that should be set. Pure democratic vote, where the majority percentage +wins, first. Second, then we will be 'set.' Then posters of ported or +new software will have to state whether their libs, etc. will look for +things in the compile/build/make process in 'standard' or 'non-standard' +format. Then it is easy to post formulas for making the thing executable. +There will then be people who refuse, for one reason or another, to change +their setup and can just link away, set up standard links, etc. +But, this should be set up via the Posix standard at first. The discussion +has to stop here and things will adjust and get moving. + +From linux Fri Feb 14 03:21:41 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <3214-0@banjo.concert.net>; Fri, 14 Feb 1992 03:21:00 -0500 +Received: from ebs.eb.ele.tue.nl by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA02389; Fri, 14 Feb 92 03:20:53 -0500 +Received: by ebs.eb.ele.tue.nl (5.65b/1.53) id AA06764; + Fri, 14 Feb 92 09:19:14 +0100 +Date: Fri, 14 Feb 92 09:19:14 +0100 +From: volf@eb.ele.tue.nl (Frank Volf) +Message-Id: <9202140819.AA06764@ebs.eb.ele.tue.nl> +To: dws@engr.uark.edu, linux-standards@concert.net +Subject: Re: Comments on Draft 2 + + +You dws@engr.uark.edu (David W. Summers) wrote: + +> I've been watching the debate about where to put Admin files and executables. +> +> What I would like is to have the executables either in /etc/bin or /usr/etc +> and the admin files themselves in /etc. +> +> Someone mentioned that they "didn't understand this fascination with keeping +> executables out of etc." +> +> Well, I would like to keep them out, because sometimes it is confusing +> (even to Sys. Admin. types like me! :-) whether or not a file (just by looking +> at the file name) is supposed to be an executable or a data file). I know, +> you can "ls -l" and see, but I like the separation of data files and executables +> like we normally have in other directories. + +I partially agree with you, becuase novice (=non sysadmin) may be confused if they +examine /etc. But /etc is not for novice users!!!! It's for sys admin people +who know what they are doing (I hope). Sys admin's know which command they need +in a particular case. We (= the sys admins) do not examine /etc to look for +some interesting executable and then try it (like many novice users do with +/usr/games). We know which command we need and where the executable resides! +So from an theoretical point of view I agree, but in practice it ain't no problem. + +> +> I agree there should probably not be any executables in /lib or /usr/lib, but +> then again, we need somewhere to put that stuff. I think that many (most?) +> times things like that should go in /etc/bin or /usr/etc. +> +> As to where root's home should go, how about "/root" ???? +I agree root files should not go in /, just because it's a mess having around all +kind of dot (and possible other) files in /. I want to keep the / as clean as +possible (only the basic directories /bin /dev /etc .......) and possible some +interesting file like /vmlinux. + + - David Summers + + + Best regards, Frank + +------------------------------------------------------------------------ +- Frank Volf INTERNET : volf@eb.ele.tue.nl - +- Eindhoven University of Technology - +- Digital Systems Group, Room EH10.16 - +- P.O. 513, - +- 5600 MB Eindhoven, The Netherlands - +------------------------------------------------------------------------ + + +From linux Fri Feb 14 03:29:16 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <3263-0@banjo.concert.net>; Fri, 14 Feb 1992 03:28:39 -0500 +Received: from daimi.aau.dk by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA02393; Fri, 14 Feb 92 03:28:35 -0500 +Received: from ananke.daimi.aau.dk by daimi.aau.dk with SMTP (5.61++/IDA-1.2.8) + id AA28657; Fri, 14 Feb 92 09:27:07 +0100 +Received: by ananke.daimi.aau.dk (5.64/1.34) id AA19946; + Fri, 14 Feb 92 09:27:03 +0100 +Date: Fri, 14 Feb 92 09:27:03 +0100 +From: tthorn@daimi.aau.dk +Message-Id: <9202140827.AA19946@ananke.daimi.aau.dk> +To: linux-standards@concert.net +Subject: Re: Comments on Draft 2, stop, stop, STOP.. + +This disscussion is getting out of hand and we are getting nowhere. +There will always be just one more remark and one more comment. +Taking the standard to vote is a *bad* idea, the hole point of +linux-standards is to make a forum for those who care to shape +*one* reference standard. Taking this to a vote will just delay +the standard (the ABC-release) to infinity. + +I say: Lets accept draft 2, and get on to more interresting +problems. It might not be everybodys dream, but it's there. +As the situations is now, theres just anarchy. + +Feel free not to flame. +/Tommy Thorn + +From linux Fri Feb 14 22:36:39 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <8008-0@banjo.concert.net>; Fri, 14 Feb 1992 22:35:57 -0500 +Received: from sun2.nsfnet-relay.ac.uk + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA14398; + Fri, 14 Feb 92 22:35:52 -0500 +Message-Id: <9202150335.AA14398@jazz.concert.net> +Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP + id <25417-0@sun2.nsfnet-relay.ac.uk>; Fri, 14 Feb 1992 18:51:44 +0000 +Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa18668; + 14 Feb 92 13:37 GMT +Date: Fri, 14 Feb 92 13:31:10 +0000 +From: db1@ukc.ac.uk +To: linux-standards@concert.net +Subject: Root, partitions, directoryes + +It seems to me that it is not clear why we need root to have +home in / and why something is needed in /bin /lib /etc + +The point is to minimize the possible damage from a disk crash +and be able to do admin even with a half broken system. + +Usually you put swap and root in one phisical disk and all the +rest of the partitions somewhere else. By doing this you +have less probability that a crash of ONE of your disks is going to +make your systm useless. + +Infact if you have swap, root and all admin commands ( essential ) +in one disk you can "repair" the damage fairly quickly. + +The point is to select whta commands are "essential" ...... to do +repairing. + +Something like + +format +mkfs +init +login +getty +sh +vi +...... + +Anyway. I don't think root HAS to have .exrc .bashrc .mailrc ...... +remembar the su is supposed to leave the environ intact +if you do not do su - + +Damiano + + +From linux Fri Feb 14 22:50:56 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <8072-0@banjo.concert.net>; Fri, 14 Feb 1992 22:49:03 -0500 +Received: from engr.uark.edu by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA14411; Fri, 14 Feb 92 22:49:00 -0500 +Received: by engr.uark.edu (/\==/\ Smail3.1.25.1 #25.3) + id ; Fri, 14 Feb 92 21:50 CST +Message-Id: +Date: Fri, 14 Feb 92 21:50 CST +From: dws@engr.uark.edu (David W. Summers) +To: db1@ukc.ac.uk +Subject: Re: Root, partitions, directoryes +Cc: linux-standards@concert.net + + +Maybe part of the problem people are having with directories in certain places +in the file system structure is that there has not been any talk (that I've +seen) about what partitions are assumed. + +I know that on a SUN, there is the / (root) partition, a /usr partition which +is read-only, a /home partition for the users and a /var partition where +/var/tmp, /var/spool, etc. are place in. + +Maybe this can help clear up why some people like directories in certain +places in the file system tree?????????? + + + - David Summers + +From linux Sat Feb 15 12:46:52 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <9403-0@banjo.concert.net>; Sat, 15 Feb 1992 12:46:12 -0500 +Received: from tsx-11.MIT.EDU by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA15347; Sat, 15 Feb 92 12:46:08 -0500 +Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA09787; + Sat, 15 Feb 92 12:45:53 -0500 +Date: Sat, 15 Feb 92 12:45:53 -0500 +From: tytso@ATHENA.MIT.edu (Theodore Ts'o) +Message-Id: <9202151745.AA09787@tsx-11.MIT.EDU> +To: dws@engr.uark.edu +Cc: db1@ukc.ac.uk, linux-standards@concert.net +In-Reply-To: David W. Summers's message of Fri, 14 Feb 92 21:50 CST, +Subject: Re: Root, partitions, directoryes +Reply-To: tytso@athena.mit.edu +Address: 1 Amherst St., Cambridge, MA 02139 +Phone: (617) 253-8091 + + Date: Fri, 14 Feb 92 21:50 CST + From: dws@engr.uark.edu (David W. Summers) + + I know that on a SUN, there is the / (root) partition, a /usr + partition which is read-only, a /home partition for the users and a + /var partition where /var/tmp, /var/spool, etc. are place in. + +Hold on a second! Sun can assume that people need to have so many +partitions, because after all, Sun is a hardware manufacturer and makes +money selling disks. Some of us may not have the luxury of throwing so +many disks/partitions at the problem. That's why I've been plugging +/usr/home. People with one /usr partition can have /usr/home be in the +same partition as /usr, and people with more disks (and by extension, +money) to burn, can mount one of their copious numbers of partitions on +/usr/home. + +In contrast, if you use /homes then you must either use a sym link from +/usr/homes to /homes, which gets confusing to users --- or you have to +use another partition. (Theoretically, I suppose you have a third +options of using one gigantic partition and mount it in /, but that's +not very satisfying either.) + +I do agree, though, that we should just adopt the draft filesystem +standard, since I doubt we will be able to get accomplish much more by +merely flaming on the subject. To give it credit, it looks a lot less +like a camel(*) than many other standards efforts which I have seen, and it +is definitely better than what we have now. + + - Ted + +(*) Definition of a camel: a horse designed by committee + +From linux Mon Feb 17 09:39:45 1992 +Return-Path: +Subject: Seen in comp.os.minix +To: linux-standards@concert.net +Date: Mon, 17 Feb 92 9:38:58 EST +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@concert.net + +Just a bit of humor to lighten your day: + +=== +Snipped from someone's signature: + +LINUXCY, n. Mental derangement caused by inability to appreciate another's + need for speed and pursuit of happiness, leading to excessive + flaming and waste of bandwidth ! +=== + +BTW: Unless there are *STRONG* complaints, I am going to post "Draft 2" of + the Directory Standards Document to alt.os.linux, and linux-activists + on Wednesday, February 19. + + I would like to release it as "Directory Standards Document 1.0" unless + there sre other ideas for a rational name.. (It will include the + header about it being completely voluntary, so we won't step on any + toes.) + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux Mon Feb 17 11:31:43 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <17912-0@banjo.concert.net>; Mon, 17 Feb 1992 11:30:09 -0500 +Received: from sirius.brunel.ac.uk + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA05826; + Mon, 17 Feb 92 11:29:51 -0500 +Received: from ccws-31.brunel.ac.uk by sirius.brunel.ac.uk with SMTP (PP) + id <01118-0@sirius.brunel.ac.uk>; Mon, 17 Feb 1992 16:27:57 +0000 +From: Roger D Binns +Message-Id: <5351.9202171627@ccws-31.brunel.ac.uk> +Subject: Re: Seen in comp.os.minix +To: abc@concert.net (Alan B Clegg) +Date: Mon, 17 Feb 92 16:27:50 BST +Cc: linux-standards@concert.net +In-Reply-To: ; from "Alan B Clegg" at Feb 17, 92 9:38 am +X-Mailer: ELM [version 2.2-hd PL 10] + +> BTW: Unless there are *STRONG* complaints, I am going to post "Draft 2" of +> the Directory Standards Document to alt.os.linux, and linux-activists +> on Wednesday, February 19. +> +> I would like to release it as "Directory Standards Document 1.0" unless +> there sre other ideas for a rational name.. (It will include the +> header about it being completely voluntary, so we won't step on any +> toes.) + +There are two things I think should be done first. + + 1) Mention this document in the install notes to give new people and + idea of what to do. + + 2) Make an mvdir available so that those of us who had to guess where + to put what when installing over the weekend can remedy the + situation ;-) + +Roger +-- ++=============================================================================+ +| cs89rdb@brunel.ac.uk Roger Binns Brunel University - UK | +|:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| +| Humans were created by water to move it uphill | ++=============================================================================+ + +From linux Mon Feb 17 12:54:05 1992 +Return-Path: +Subject: banjo.concert.net off-the-air +To: linux-standards@concert.net +Date: Mon, 17 Feb 92 12:52:39 EST +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@concert.net + +Due to work (*yuck*) reasons, I have to upgrade banjo.concert.net from SunOS +4.1.1 to 4.1.2, and the easiest way to do that is to start over from scratch. + +I will be doing this starting this afternoon (about 2:00pm EDT) and will be +done (hopefully by late tomorrow afternoon). + +The Linux-Standards mailing list, as well as the anonymous FTP archives on +banjo will be out-of-service till I get everything going on this end. I will +continue to recieve mail sent to abc@concert.net, or abc@jazz.concert.net. + +Sorry for the inconvenience, but work does come first... + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux-standards-request@concert.net Wed Feb 19 14:03:15 1992 +Return-Path: +Received: from concert.net by banjo.concert.net id <11488-0@banjo.concert.net>; + Wed, 19 Feb 1992 14:03:00 -0500 +Subject: List is back... +To: linux-standards@concert.net +Date: Wed, 19 Feb 92 14:02:56 EST +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@concert.net + +The linux-standards mailing list is back in operation. + +The FTP mirrors will be restarted this afternoon, depending on my disk space +crunch. Anyone have a couple of gig to donate? 8-) + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux-standards-request@concert.net Wed Feb 19 20:07:38 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <02175-0@banjo.concert.net>; Wed, 19 Feb 1992 20:07:26 -0500 +Received: from relay1.UU.NET by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA09400; Wed, 19 Feb 92 20:07:24 -0500 +Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET + with SMTP (5.61/UUNET-internet-primary) id AA09852; + Wed, 19 Feb 92 20:07:17 -0500 +Received: from optigfx.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) + id 200639.16000; Wed, 19 Feb 1992 20:06:39 EST +Received: from optisun17.optigfx.com by optigfx.com (4.1/SMI-4.1) id AA06241; + Wed, 19 Feb 92 16:54:29 PST +Received: by optisun17.optigfx.com (4.1/SMI-4.1) id AA04406; + Wed, 19 Feb 92 16:52:46 PST +Date: Wed, 19 Feb 92 16:52:46 PST +From: optigfx!optisun17!mrm@uunet.UU.NET (Mike Murphy) +Message-Id: <9202200052.AA04406@optisun17.optigfx.com> +To: linux-standards@concert.net +Subject: Re: Seen in comp.os.minix + +In the also unforgettable words of Bruce Varney +>In the unforgettable words of Alan B Clegg: +>-> +>->Just a bit of humor to lighten your day: +>-> +>->BTW: Unless there are *STRONG* complaints, I am going to post "Draft 2" of +>-> the Directory Standards Document to alt.os.linux, and linux-activists +>-> on Wednesday, February 19. + +>Admin binaries should be in /etc. That is my only complaint, and it +>is a *STRONG* one. +>-> +Strongly agreed that admin binaries should be in /etc, including, but not +limited to /etc/init. I also have strong feelings about this. I seem to +remember a reference to /usr/uucp, too, rather than to /usr/lib/uucp. I +would prefer the /usr/lib/uucp /usr/spool/uucp pair, again, pretty strong +feelings... + +The U**X rationale for the distribution of files between /etc, /bin, /usr/bin, +/lib, and /usr/lib weren't bad. I feel, however, that /usr/spool/cron and +/usr/lib/cron are misused in a "normal" U**X environment. It seems that +/usr/lib/cron should be used for the tables and definitions and such, +and that /usr/spool/cron should be used for the logs. Oh, well. Maybe the +tables and such would have been better in /etc/cron.d, analogous to /etc/rc.d, +/etc/rc0.d, and the like. +-- +Mike Murphy mrm@Optigfx.COM ucsd!optigfx!mrm +1 619 292 6060 x 265 +Optigraphics Corporation 9339 Carroll Park Drive San Diego, CA 92121 +The opinion(s) expressed above are mine and not those of my employer. + +From linux-standards-request@concert.net Wed Feb 19 23:11:07 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <03229-0@banjo.concert.net>; Wed, 19 Feb 1992 23:10:56 -0500 +Received: from tsx-11.MIT.EDU by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA10138; Wed, 19 Feb 92 23:10:54 -0500 +Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA15221; + Wed, 19 Feb 92 23:10:50 -0500 +Date: Wed, 19 Feb 92 23:10:50 -0500 +From: eichin@ATHENA.MIT.EDU ("Mark W. Eichin") +Message-Id: <9202200410.AA15221@tsx-11.MIT.EDU> +To: optigfx!optisun17!mrm@uunet.UU.NET +Cc: linux-standards@concert.net +In-Reply-To: Mike Murphy's message of Wed, 19 Feb 92 16:52:46 PST <9202200052.AA04406@optisun17.optigfx.com> +Subject: re: Seen in comp.os.minix + +A few people are... +>>> Strongly agreed that admin binaries should be in /etc, including, but not + Sorry... either have binaries there, or config files -- *Not* +both. The BSD 4.4 model (which I think is what one of the draft posix +standards is related to, if not derived from) has config files in /etc +and executables in /usr/etc/ (DEC Ultrix and SunOS have already +adopted this.) Having executables in /etc may be "traditional", but +that's just because it is a traditional mistake... + _Mark_ + MIT Student Information Processing Board + + +From linux-standards-request@concert.net Thu Feb 20 02:53:38 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <03812-0@banjo.concert.net>; Thu, 20 Feb 1992 02:53:28 -0500 +Received: from sun2.nsfnet-relay.ac.uk + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA10568; + Thu, 20 Feb 92 02:53:21 -0500 +Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk + via JANET with NIFTP id <1262-0@sun2.nsfnet-relay.ac.uk>; + Thu, 20 Feb 1992 07:19:16 +0000 +Message-Id: <20 Feb 92 07:14:37 GMT ZLSIIAL@UK.AC.MCC.CMS> +Date: Thu, 20 Feb 92 07:14:37 GMT +From: LeBlanc@manchester-computing-centre.ac.uk +Myname: A. V. Le Blanc +To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@concert.net> +Subject: location of logs + + +I note with concern a reference to various logs going in +/usr/spool. + +The task of making Linux better requires a balance between +avoiding too much peculiarity (making Linux more 'standard') +and pursuing simplicity (helping idiots set up and use Linux). + +One of the most irritating tasks I have as a sysadmin is cleaning +out thousands of log files. On my systems there are logs in +/etc, in /usr/adm, in /usr/etc, in /usr/spool, and in literally +thousands of user directories (x/motif session error logs). +Preventing this rubbish from piling up is a major nuisance. +One advantage of having /var is to get all the stuff in one place. +Another is to put all the growing files on one partition, where it +can cause less havoc in the file system when it gets full. This +makes administering the system simpler. If conformity is threatened, +we can always make /etc/wtmp, /usr/adm/syslog, /usr/spool/lp/log, +etc, be symbolic links to files in /var. That way security can be +checked, and then all logs deleted, e.g., by + + find /var -type f -exec rm {} \; + +which could be put in a script for the non-Unix literate. + + A. V. Le Blanc + LeBlanc@mcc.ac.uk + +From linux-standards-request@concert.net Thu Feb 20 03:20:21 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <03917-0@banjo.concert.net>; Thu, 20 Feb 1992 03:20:09 -0500 +Received: from sun2.nsfnet-relay.ac.uk + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA10638; + Thu, 20 Feb 92 03:20:06 -0500 +Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk + via JANET with NIFTP id <2437-0@sun2.nsfnet-relay.ac.uk>; + Thu, 20 Feb 1992 08:11:57 +0000 +Message-Id: <20 Feb 92 07:32:41 GMT ZLSIIAL@UK.AC.MCC.CMS> +Date: Thu, 20 Feb 92 07:32:41 GMT +From: LeBlanc@manchester-computing-centre.ac.uk +Myname: A. V. Le Blanc +To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@concert.net> +Subject: admin binaries and configuration + + +Two points: + +1) To decide that something is a binary for administrative + purposes only is harder on Linux than it is on most systems. + For example, you should be able to format, mkfs, and mount + a floppy disk without being root. For this reason, format, + mkfs, mount, umount, fsck, etc., may well need to be in /bin + instead of in /etc, where most Unixes would put them. On + the other hand, I think init and update should probably not + be in /bin, since even root ought not normally execute them + as commands. This is why I suggested in an earlier note that + they ought to go in /lib. Someone objected that /lib ought + not contain executables. What about /lib/cpp, /usr/lib/sendmail, + and such executables, which are traditionally in library + directories? Personally I suspect cpp belongs in a bin + somewhere. What about daemons? + +2) I suggest that files be distinguished into + + a) Configuration files (passwd, group, inetd.conf). + b) Executables and scripts which only root should run, + even on Linux (telinit, shutdown, reboot). + c) Executables which not even root should normally run + (update, gated, inetd). + + Now, when I think in these terms, I find it awfully difficult + to be clear about these categories. What about rc, for + example; does it belong in a, in b, or in c? If we have a + special directory for root-only executables, shouldn't all, + or almost all, of (c) be in it as well as (b), since under + some circumstances root may want to start these off manually? + + In short, while I sympathise most strongly with those who + would like to see the stuff in /etc be homogeneous, I am not + at all certain that it can be done. At best we might put + configuration files in /etc and the rest in /etc/bin, or + binaries in /etc and the rest in /etc/conf. + +A. V. Le Blanc +University of Manchester +LeBlanc@mcc.ac.uk + +From linux-standards-request@banjo.concert.net Thu Feb 20 10:48:24 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <07877-0@banjo.concert.net>; Thu, 20 Feb 1992 10:47:57 -0500 +Received: from engr.uark.edu by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA14932; Thu, 20 Feb 92 10:47:54 -0500 +Received: by engr.uark.edu (/\==/\ Smail3.1.25.1 #25.3) + id ; Thu, 20 Feb 92 09:49 CST +Message-Id: +Date: Thu, 20 Feb 92 09:49 CST +From: dws@engr.uark.edu (David W. Summers) +To: linux-standards@concert.net +Subject: re: Seen in comp.os.minix + + +----- Begin Included Message ----- + +>From concert.net!linux-standards-request Wed Feb 19 22:14:24 1992 +Date: Wed, 19 Feb 92 23:10:50 -0500 +From: eichin@ATHENA.MIT.EDU ("Mark W. Eichin") +To: optigfx!optisun17!mrm@uunet.UU.NET +Cc: linux-standards@concert.net +Subject: re: Seen in comp.os.minix +Content-Length: 566 + +A few people are... +>>> Strongly agreed that admin binaries should be in /etc, including, but not + Sorry... either have binaries there, or config files -- *Not* +both. The BSD 4.4 model (which I think is what one of the draft posix +standards is related to, if not derived from) has config files in /etc +and executables in /usr/etc/ (DEC Ultrix and SunOS have already +adopted this.) Having executables in /etc may be "traditional", but +that's just because it is a traditional mistake... + _Mark_ + MIT Student Information Processing Board + + + +----- End Included Message ----- + +Hooray for our side! :-) + +This is what I was trying to get across in my previous posting. + +I hadn't realized that several people have STRONG feelings against this! + +I completely agree with having just admin. files in /etc and executables in +/usr/etc. + + - David Summers + +From linux-standards-request@banjo.concert.net Thu Feb 20 10:53:30 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <08063-0@banjo.concert.net>; Thu, 20 Feb 1992 10:52:55 -0500 +Received: from engr.uark.edu by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA14993; Thu, 20 Feb 92 10:52:48 -0500 +Received: by engr.uark.edu (/\==/\ Smail3.1.25.1 #25.3) + id ; Thu, 20 Feb 92 09:54 CST +Message-Id: +Date: Thu, 20 Feb 92 09:54 CST +From: dws@engr.uark.edu (David W. Summers) +To: linux-standards@concert.net +Subject: location of logs + + +----- Begin Included Message ----- + +>From concert.net!linux-standards-request Thu Feb 20 02:02:27 1992 +Date: Thu, 20 Feb 92 07:14:37 GMT +From: LeBlanc@manchester-computing-centre.ac.uk +Myname: A. V. Le Blanc +To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@concert.net> +Subject: location of logs +Content-Length: 1161 + + +I note with concern a reference to various logs going in +/usr/spool. + +The task of making Linux better requires a balance between +avoiding too much peculiarity (making Linux more 'standard') +and pursuing simplicity (helping idiots set up and use Linux). + +One of the most irritating tasks I have as a sysadmin is cleaning +out thousands of log files. On my systems there are logs in +/etc, in /usr/adm, in /usr/etc, in /usr/spool, and in literally +thousands of user directories (x/motif session error logs). +Preventing this rubbish from piling up is a major nuisance. +One advantage of having /var is to get all the stuff in one place. +Another is to put all the growing files on one partition, where it +can cause less havoc in the file system when it gets full. This +makes administering the system simpler. If conformity is threatened, +we can always make /etc/wtmp, /usr/adm/syslog, /usr/spool/lp/log, +etc, be symbolic links to files in /var. That way security can be +checked, and then all logs deleted, e.g., by + + find /var -type f -exec rm {} \; + +which could be put in a script for the non-Unix literate. + + A. V. Le Blanc + LeBlanc@mcc.ac.uk + + +----- End Included Message ----- + +YES YES YES! + +Notice /var/log directory in SunOS. /var is (usually) a separate partition +in SunOS and the Sys. Admin. chooses how big he will make it. + +This makes it VERY NICE from a Sys. Admin. point of view. If I DON'T have +room for a /var partition, then I usually make it a sym-link to somewhere +that has extra space left over for misc. stuff. + + - David Summers + +From linux-standards-request@banjo.concert.net Thu Feb 20 11:06:12 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <08838-0@banjo.concert.net>; Thu, 20 Feb 1992 11:05:49 -0500 +Received: from daimi.aau.dk by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA15116; Thu, 20 Feb 92 11:05:46 -0500 +Received: from bentley.daimi.aau.dk by daimi.aau.dk + with SMTP (5.61++/IDA-1.2.8) id AA06578; + Thu, 20 Feb 92 17:05:38 +0100 +Received: by bentley.daimi.aau.dk (5.64/1.34) id AA24073; + Thu, 20 Feb 92 17:05:33 +0100 +Date: Thu, 20 Feb 92 17:05:33 +0100 +From: tthorn@daimi.aau.dk +Message-Id: <9202201605.AA24073@bentley.daimi.aau.dk> +To: linux-standards@concert.net +In-Reply-To: David W. Summers's message of Thu, 20 Feb 92 09:49 CST +Subject: /etc and /usr/etc [was re: Seen in comp.os.minix] + +> From: dws@engr.uark.edu (David W. Summers) +> +> I completely agree with having just admin. files in /etc and executables +> in /usr/etc. + +Bzzzz. Wrong guess Hans:-) The consequence of this would be that things like +init would be in /usr/etc, which might not even be mounted at the time +init should be run. + +In retrospect I also think that /bin/init is a bad idea, but then it should +be /lib/init. + +...../lib should contrain libraries, support files *and* executables which +shouldn't be in anyones path. + +And with this small change I'd like to see the Draft accepted. + +/Tommy Thorn + +From linux-standards-request@banjo.concert.net Thu Feb 20 11:43:14 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <11701-0@banjo.concert.net>; Thu, 20 Feb 1992 11:41:33 -0500 +Received: from banjo.concert.net by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA15510; Thu, 20 Feb 92 11:41:11 -0500 +Message-Id: <9202201641.AA15510@jazz.concert.net> +Received: from banjo.concert.net by banjo.concert.net + id <07999-0@banjo.concert.net>; Thu, 20 Feb 1992 10:51:39 -0500 +Subject: re: Seen in comp.os.minix +To: dws@engr.uark.edu (David W. Summers) +Date: Thu, 20 Feb 92 10:51:35 EST +Cc: linux-standards@concert.net +In-Reply-To: ; from "David W. Summers" at Feb 20, 92 9:49 am +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@banjo.concert.net + +> I completely agree with having just admin. files in /etc and executables in +> /usr/etc. + +Ok, put init in /usr/etc, and make sure /usr is mounted just before you +exec it. + +Minor problem. + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux-standards-request@banjo.concert.net Thu Feb 20 11:43:15 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <11702-0@banjo.concert.net>; Thu, 20 Feb 1992 11:41:33 -0500 +Received: from banjo.concert.net by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA15522; Thu, 20 Feb 92 11:41:16 -0500 +Message-Id: <9202201641.AA15522@jazz.concert.net> +Received: from banjo.concert.net by banjo.concert.net + id <08868-0@banjo.concert.net>; Thu, 20 Feb 1992 11:07:59 -0500 +Subject: Re: location of logs +To: dws@engr.uark.edu (David W. Summers) +Date: Thu, 20 Feb 92 11:07:55 EST +Cc: linux-standards@concert.net +In-Reply-To: ; from "David W. Summers" at Feb 20, 92 9:54 am +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@banjo.concert.net + +> From: LeBlanc@manchester-computing-centre.ac.uk + +[ Discussion of /var ] + +> find /var -type f -exec rm {} \; + +You are kidding, right? /var/spool/mail ... *POOF* /var/spool/news *POOF* + +*NOT A GOOD IDEA* + +> which could be put in a script for the non-Unix literate. + +Linux is not for 'the non-Unix literate'. + +To which David W. Summers replies: + +> Notice /var/log directory in SunOS. /var is (usually) a separate partition +> in SunOS and the Sys. Admin. chooses how big he will make it. + +The sysadm chooses how large *EVERY* partition is. What matter is it that +it is hanging off of /usr or /var? + +> This makes it VERY NICE from a Sys. Admin. point of view. If I DON'T have +> room for a /var partition, then I usually make it a sym-link to somewhere +> that has extra space left over for misc. stuff. + +So what is the difference here of mounting something on top of /usr/adm, or +making *IT* a symlink? + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux-standards-request@banjo.concert.net Thu Feb 20 11:43:31 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <11706-0@banjo.concert.net>; Thu, 20 Feb 1992 11:41:33 -0500 +Received: from banjo.concert.net by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA15529; Thu, 20 Feb 92 11:41:21 -0500 +Message-Id: <9202201641.AA15529@jazz.concert.net> +Received: from banjo.concert.net by banjo.concert.net + id <08926-0@banjo.concert.net>; Thu, 20 Feb 1992 11:15:33 -0500 +Subject: Re: /etc and /usr/etc [was re: Seen in comp.os.minix] +To: tthorn@daimi.aau.dk +Date: Thu, 20 Feb 92 11:15:29 EST +Cc: linux-standards@concert.net +In-Reply-To: <9202201605.AA24073@bentley.daimi.aau.dk>; from "tthorn@daimi.aau.dk" at Feb 20, 92 5:05 pm +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@banjo.concert.net + +> In retrospect I also think that /bin/init is a bad idea, but then it should +> be /lib/init. + +Agreed. + +> ...../lib should contrain libraries, support files *and* executables which +> shouldn't be in anyones path. +> +> And with this small change I'd like to see the Draft accepted. + +Agreed. I will make the change. All in favor? All opposed? Good. +It passes. (seriously, one last day to bring up comments). + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux-standards-request@banjo.concert.net Thu Feb 20 12:41:25 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <12131-0@banjo.concert.net>; Thu, 20 Feb 1992 12:41:12 -0500 +Received: from tsx-11.MIT.EDU by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA16308; Thu, 20 Feb 92 12:41:06 -0500 +Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA16696; + Thu, 20 Feb 92 12:40:14 -0500 +Date: Thu, 20 Feb 92 12:40:14 -0500 +From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) +Message-Id: <9202201740.AA16696@tsx-11.MIT.EDU> +To: dws@engr.uark.edu +Cc: linux-standards@concert.net +In-Reply-To: David W. Summers's message of Thu, 20 Feb 92 09:49 CST, +Subject: Re: Seen in comp.os.minix +Reply-To: tytso@athena.mit.edu +Address: 1 Amherst St., Cambridge, MA 02139 +Phone: (617) 253-8091 + + Sorry... either have binaries there, or config files -- *Not* + both. The BSD 4.4 model (which I think is what one of the draft posix + standards is related to, if not derived from) has config files in /etc + and executables in /usr/etc/ (DEC Ultrix and SunOS have already + adopted this.) Having executables in /etc may be "traditional", but + that's just because it is a traditional mistake... + +No, that's not the BSD 4.4 model; they have /sbin for the admin +binaries. The problem is that you need to start /usr/etc/init before +/usr is mounted.... + +Look, this seems to be going nowhere. We can't just blindly point and +say look! BSD 4.3 did it this way! Sun OS did it that way! The only +reason why we were doing this was that we don't want to screw users +who have always been used to finding programs in particular places +(/etc/mount, /bin/grep, /bin/ed, etc., etc.). But aside from that, we +need to architect something that works as a cohesive whole. + +Putting init in /usr/etc when it was previously assumed that /usr might +be a mounted partition, all in the name of "Horray for our side!" is +going to result in a camel --- a horse designed by a committee. Before +we get all wrapped up in aesthetics, let's come up with a cohesive +document THAT WORKS. + + Slightly annoyed, + + - Ted + +From linux-standards-request@banjo.concert.net Thu Feb 20 23:26:29 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <21295-0@banjo.concert.net>; Thu, 20 Feb 1992 16:05:35 -0500 +Received: from relay1.UU.NET by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA21429; Thu, 20 Feb 92 16:05:31 -0500 +Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET + with SMTP (5.61/UUNET-internet-primary) id AA14190; + Thu, 20 Feb 92 16:05:21 -0500 +Received: from optigfx.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) + id 160427.9260; Thu, 20 Feb 1992 16:04:27 EST +Received: from optisun17.optigfx.com by optigfx.com (4.1/SMI-4.1) id AA18092; + Thu, 20 Feb 92 12:38:24 PST +Received: by optisun17.optigfx.com (4.1/SMI-4.1) id AA04793; + Thu, 20 Feb 92 12:36:41 PST +Date: Thu, 20 Feb 92 12:36:41 PST +From: optigfx!optisun17!mrm@uunet.UU.NET (Mike Murphy) +Message-Id: <9202202036.AA04793@optisun17.optigfx.com> +To: uunet!ATHENA.MIT.EDU!eichin@uunet.UU.NET +Subject: re: Seen in comp.os.minix +Cc: linux-standards@concert.net + +_Mark_ writes: + +>A few people are... +still :-) +>>>> Strongly agreed that admin binaries should be in /etc, including, but not +> Sorry... either have binaries there, or config files -- *Not* +>both. The BSD 4.4 model (which I think is what one of the draft posix +>standards is related to, if not derived from) has config files in /etc +>and executables in /usr/etc/ (DEC Ultrix and SunOS have already +>adopted this.) Having executables in /etc may be "traditional", but +>that's just because it is a traditional mistake... + +Not a mistake :-) It follows the KISS principle, which, I would suggest, has been +sorely ignored in "modern" U**X. Again, oh, well. + +I kind of like the root path "/bin:/etc:/usr/bin". The implication is that the +executables required for system maintenance/startup are in /etc (maybe symlinks, +who cares except for KISS), and that they are not, nor do they need to be, in the +"normal" user path. I'd also like to see the permissions for something like +/etc/fsck be 0110, owned by root and group sys or system or the like. + +Sticking executables in /usr/etc may be or may not be a "good thing" otherwise, but +it can really make backup/restore cycles a pain. It also can make life a royal pain +if in single user mode the /usr filesystem(s) aren't mounted. It is shortsighted to +be a purist WRT splitting of configuration and executable, I think. + +I would propose a far simpler directory structure: + +/ root, to contain as little as possible, just what's required for + single user mode + +At the next lowest level: +/bin/ commonly used binaries, necessary for single user nothing else but + the root device mounted +/dev/ device special files +/etc/ system configuration, startup, maintenance +/export/ mount point for directories/filesystems to be exported over a network +/home/ mount point for directories of groups of users homed on the system +/lib/ libraries required for system operation, e.g., shared libraries, just what's + required for single user mode +/lost+found/ disaster recovery :-) +/usr/ mount point for system components required for more than single user + maintenance functions, such as /usr/adm/, /usr/bin/, /usr/lib/, and + /usr/spool +/vmlinux :-) + +Note that I specifically leave out /mnt + +And then, heirarchically, stuff like: +/dev/dsk/ disks +/dev/lp/ printers +/dev/net/ networks +/dev/tty/ locally connected serial ports +.. +/etc/conf.d/ configuration +.. +/etc/rc0.d/ single user rc +/etc/rc2.d/ multi-user rc (and so on...) +.. + +Setting up a system that won't run single user with nothing mounted is probably a pretty +bad idea. Setting up a system that can't be expanded to cope with 4 SCSI controllers with +2 tapes, 10 disk drives, 6 printers, and a coffee pot interface is also probably a shame +if it can be easily avoided. +-- +Mike Murphy mrm@Optigfx.COM ucsd!optigfx!mrm +1 619 292 6060 x 265 +Optigraphics Corporation 9339 Carroll Park Drive San Diego, CA 92121 +The opinion(s) expressed above are mine and not those of my employer. + +From linux-standards-request@banjo.concert.net Thu Feb 20 23:26:30 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <22204-0@banjo.concert.net>; Thu, 20 Feb 1992 16:07:58 -0500 +Received: from relay1.UU.NET by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA21533; Thu, 20 Feb 92 16:07:50 -0500 +Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET + with SMTP (5.61/UUNET-internet-primary) id AA14168; + Thu, 20 Feb 92 16:05:18 -0500 +Received: from optigfx.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) + id 160429.9288; Thu, 20 Feb 1992 16:04:29 EST +Received: from optisun17.optigfx.com by optigfx.com (4.1/SMI-4.1) id AA18540; + Thu, 20 Feb 92 12:52:28 PST +Received: by optisun17.optigfx.com (4.1/SMI-4.1) id AA04853; + Thu, 20 Feb 92 12:50:45 PST +Date: Thu, 20 Feb 92 12:50:45 PST +From: optigfx!optisun17!mrm@uunet.UU.NET (Mike Murphy) +Message-Id: <9202202050.AA04853@optisun17.optigfx.com> +To: uunet!manchester-computing-centre.ac.uk!LeBlanc@uunet.UU.NET +Subject: Re: admin binaries and configuration +Cc: linux-standards@concert.net + +A. V. Le Blanc writes: + +>Two points: +> +>1) To decide that something is a binary for administrative +> purposes only is harder on Linux than it is on most systems. +> For example, you should be able to format, mkfs, and mount +> a floppy disk without being root. For this reason, format, +> mkfs, mount, umount, fsck, etc., may well need to be in /bin +> instead of in /etc, where most Unixes would put them. On +> the other hand, I think init and update should probably not +> be in /bin, since even root ought not normally execute them +> as commands. This is why I suggested in an earlier note that +> they ought to go in /lib. Someone objected that /lib ought +> not contain executables. What about /lib/cpp, /usr/lib/sendmail, +> and such executables, which are traditionally in library +> directories? Personally I suspect cpp belongs in a bin +> somewhere. What about daemons? + +The security problems mounting a floppy disk are interesting :-) +It may well be desirable to limit access to such functions as format, +fsck, mkfs, mount, et.al. in order to maintain a stable computing +environment. I am suggesting here that linux and what it becomes +could be in a large multi-user environment, a process control +environment, a who-knows-how-used envrionment. If it's a system +maintenance function, e.g., fsck, then I think it ought to live +in /etc. Just opinion, but my use of a system may not match someone +elses. + +> +>2) I suggest that files be distinguished into +> +> a) Configuration files (passwd, group, inetd.conf). +> b) Executables and scripts which only root should run, +> even on Linux (telinit, shutdown, reboot). +> c) Executables which not even root should normally run +> (update, gated, inetd). +> +> Now, when I think in these terms, I find it awfully difficult +> to be clear about these categories. What about rc, for +> example; does it belong in a, in b, or in c? If we have a +> special directory for root-only executables, shouldn't all, +> or almost all, of (c) be in it as well as (b), since under +> some circumstances root may want to start these off manually? +> +> In short, while I sympathise most strongly with those who +> would like to see the stuff in /etc be homogeneous, I am not +> at all certain that it can be done. At best we might put +> configuration files in /etc and the rest in /etc/bin, or +> binaries in /etc and the rest in /etc/conf. + +Sounds pretty good, except for the dire consequences of having format +live in /bin :-) +-- +Mike Murphy mrm@Optigfx.COM ucsd!optigfx!mrm +1 619 292 6060 x 265 +Optigraphics Corporation 9339 Carroll Park Drive San Diego, CA 92121 +The opinion(s) expressed above are mine and not those of my employer. + +From linux-standards-request@banjo.concert.net Thu Feb 20 23:26:31 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <22208-0@banjo.concert.net>; Thu, 20 Feb 1992 16:07:58 -0500 +Received: from relay2.UU.NET by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA21535; Thu, 20 Feb 92 16:07:51 -0500 +Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET + with SMTP (5.61/UUNET-internet-primary) id AA25603; + Thu, 20 Feb 92 16:05:25 -0500 +Received: from optigfx.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) + id 160428.9273; Thu, 20 Feb 1992 16:04:28 EST +Received: from optisun17.optigfx.com by optigfx.com (4.1/SMI-4.1) id AA18216; + Thu, 20 Feb 92 12:45:44 PST +Received: by optisun17.optigfx.com (4.1/SMI-4.1) id AA04845; + Thu, 20 Feb 92 12:44:02 PST +Date: Thu, 20 Feb 92 12:44:02 PST +From: optigfx!optisun17!mrm@uunet.UU.NET (Mike Murphy) +Message-Id: <9202202044.AA04845@optisun17.optigfx.com> +To: uunet!manchester-computing-centre.ac.uk!LeBlanc@uunet.UU.NET +Subject: Re: location of logs +Cc: linux-standards@concert.net + +A. V. Le Blanc writes: + +>I note with concern a reference to various logs going in +>/usr/spool. + +The nit I was picking was the the log files that end up +in /usr/lib, which I think should be a pretty static kind +of place. Better to have the log files for cron show up in +/usr/spool/cron rather than in /usr/lib/cron. Also better +to have the configuration for cron in /usr/lib/cron rather +than in /usr/spool/cron. That was my point. WRT to logfiles +being strewn throughout a directory heirarchy, I agree that +it's a pain to administer. Log trimming is a chore no matter +how it's to be done. Symbolic links could make things easier. +The above is opinion to be taken with more than one grain +of salt... +-- +Mike Murphy mrm@Optigfx.COM ucsd!optigfx!mrm +1 619 292 6060 x 265 +Optigraphics Corporation 9339 Carroll Park Drive San Diego, CA 92121 +The opinion(s) expressed above are mine and not those of my employer. + +From linux-standards-request@banjo.concert.net Fri Feb 21 08:43:10 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <01623-0@banjo.concert.net>; Fri, 21 Feb 1992 08:41:41 -0500 +Received: from ux.acs.umn.edu by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA23802; Fri, 21 Feb 92 01:32:56 -0500 +Received: by ux.acs.umn.edu (5.65c/) id AA17605; Fri, 21 Feb 1992 00:33:55 -0600 +From: "Mr. Big Stuff" +Message-Id: <199202210633.AA17605@ux.acs.umn.edu> +Subject: Re: location of logs +To: linux-standards@concert.net +Date: Fri, 21 Feb 92 0:33:49 CST +In-Reply-To: ; from "David W. Summers" at Feb 20, 92 9:54 am +X-Mailer: ELM [version 2.3 PL11] + +David W. Summers must have playing with Crayolas when s/he/it/them wrote: +>LeBlanc@manchester-computing-centre.ac.uk writes: +>>One of the most irritating tasks I have as a sysadmin is cleaning +>>out thousands of log files. On my systems there are logs in +... +>>One advantage of having /var is to get all the stuff in one place. +>>Another is to put all the growing files on one partition, where it +>>can cause less havoc in the file system when it gets full. This +>>makes administering the system simpler. If conformity is threatened, + +>YES YES YES! +>Notice /var/log directory in SunOS. /var is (usually) a separate partition +>in SunOS and the Sys. Admin. chooses how big he will make it. + +In spite of my standard reply header, I agree with all of the above. +Putting all the logs in one place would make a *big* difference in the ease +of maintaining linux. And making sure that (say) a 30+Meg logfile doesn't +bring your system to it's knees is a good thing. Not that I've seen that :-) + +Since there is already a 'standard' place to put log files (/var/log) I +won't even think of suggesting /log :-) + +The proposed standard file system should be changed to reflect a log +directory, IMHO. + +-- +Brian +brian@ux.acs.umn.edu + +From linux-standards-request@banjo.concert.net Fri Feb 21 08:43:33 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <01678-0@banjo.concert.net>; Fri, 21 Feb 1992 08:42:22 -0500 +Received: from tsx-11.MIT.EDU by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA23543; Fri, 21 Feb 92 00:04:45 -0500 +Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA18977; + Fri, 21 Feb 92 00:04:40 -0500 +Date: Fri, 21 Feb 92 00:04:40 -0500 +From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) +Message-Id: <9202210504.AA18977@tsx-11.MIT.EDU> +To: optigfx!optisun17!mrm@uunet.UU.NET +Cc: linux-standards@concert.net +In-Reply-To: Mike Murphy's message of Thu, 20 Feb 92 12:36:41 PST, <9202202036.AA04793@optisun17.optigfx.com> +Subject: Re: Seen in comp.os.minix +Reply-To: tytso@athena.mit.edu +Address: 1 Amherst St., Cambridge, MA 02139 +Phone: (617) 253-8091 + + Date: Thu, 20 Feb 92 12:36:41 PST + From: optigfx!optisun17!mrm@uunet.UU.NET (Mike Murphy) + + Not a mistake :-) It follows the KISS principle, which, I would + suggest, has been sorely ignored in "modern" U**X. Again, oh, well..... + + [....] + + I would propose a far simpler directory structure: + + And then, heirarchically, stuff like: + /dev/dsk/ disks + /dev/lp/ printers + /dev/net/ networks + /dev/tty/ locally connected serial ports + .. + /etc/conf.d/ configuration + .. + /etc/rc0.d/ single user rc + /etc/rc2.d/ multi-user rc (and so on...) + .. + +Somehow, I have trouble reconciling your first statement about KISS with +your proposal where you have hierarchies under /dev. I suspect this +will break more than a few programs, as well as people's mindsets. (It +would certainly break my stock login scripts, which play funky games +with `ttyname`.) + +I am correct in assuming that the current draft proposal does *NOT* +suggest use of such a hierarchy in /dev, right? If so, I hope we keep +it that way.... + + - Ted + + + +From linux-standards-request@banjo.concert.net Fri Feb 21 08:49:30 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <01560-0@banjo.concert.net>; Fri, 21 Feb 1992 08:40:59 -0500 +Received: from golem.wcc.govt.nz by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA23877; Fri, 21 Feb 92 02:42:54 -0500 +Received: from csc.wcc.govt.nz by golem.wcc.govt.nz id ; + Fri, 21 Feb 92 20:43:45 +1300 +Received: by csc.wcc.govt.nz (MX V3.0) id 1111; Fri, 21 Feb 1992 20:45:08 EST +Sender: hamilton +Date: Fri, 21 Feb 1992 20:45:02 EST +From: hamilton@csc.wcc.govt.nz +To: linux-standards@concert.net +Cc: hamilton@csc.wcc.govt.nz +Message-Id: <00956816.E2430520.1111@csc.wcc.govt.nz> +Subject: Seen in comp.os.minix + + +I know it's not standard, but how about /etc/bin and /etc/log, and/or +/usr/etc/bin and /usr/etc/log as appropriate. Or if we want to keep +things "standard", I would vote with KISS, i.e. "/bin:/etc:/usr/bin", +with no links, symbolic or otherwise. + +I very much dislike the idea of having to have /usr/etc around to get +at admin binaries. + +As for cleaning up log files, I would suggest a standard clean_logs +shell script (or some similar scheme). + + + +From linux-standards-request@banjo.concert.net Fri Feb 21 12:36:02 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <15234-0@banjo.concert.net>; Fri, 21 Feb 1992 12:35:23 -0500 +Received: from relay1.UU.NET by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA01425; Fri, 21 Feb 92 12:35:18 -0500 +Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET + with SMTP (5.61/UUNET-internet-primary) id AA06182; + Fri, 21 Feb 92 12:35:06 -0500 +Received: from optigfx.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) + id 123434.9470; Fri, 21 Feb 1992 12:34:34 EST +Received: from optisun17.optigfx.com by optigfx.com (4.1/SMI-4.1) id AA18954; + Thu, 20 Feb 92 13:26:08 PST +Received: by optisun17.optigfx.com (4.1/SMI-4.1) id AA04998; + Thu, 20 Feb 92 13:24:26 PST +Date: Thu, 20 Feb 92 13:24:26 PST +From: optigfx!optisun17!mrm@uunet.UU.NET (Mike Murphy) +Message-Id: <9202202124.AA04998@optisun17.optigfx.com> +To: uunet!banjo.concert.net!abc@uunet.UU.NET +Subject: Re: /etc and /usr/etc [was re: Seen in comp.os.minix] +Cc: linux-standards@concert.net + +>> In retrospect I also think that /bin/init is a bad idea, but then it should +>> be /lib/init. + +>Agreed. + +>> ...../lib should contrain libraries, support files *and* executables which +>> shouldn't be in anyones path. +Agreed :-) The trick is to minimize what is in the device or partition of a +device that contains root (/). /lib should therefore contain only the minimal +stuff to allow a system to run. Same for /etc and /bin. Just enough to let the +system repair itself. Symlink the rest if it pleases, but it is really a bad +idea to set up a system that requires itself to be whole to make itself whole. + +Or maybe rename it from linux to catch22ix :-) + +Seriously, from a practical standpoint, what I'd like to be able to do is + +1) Boot a WRITE-PROTECTED diskette. +2) Futz with my hard drive(s) from said standalone diskette system to set + 'em up, format, partition, mkfs, mount and such. +3) Use some simple utility like tar to suck the rest of a distribution from + diskette, tape if I'm lucky, or network if I'm luckier. +4) Reboot from the hard drive. +5) Merrily configure my system and do useful work... + +I'd be disappointed if a Draft didn't take such considerations to heart. + +>> +>> And with this small change I'd like to see the Draft accepted. + +>Agreed. I will make the change. All in favor? All opposed? Good. +>It passes. (seriously, one last day to bring up comments). +Disagreed :-) + +This ignores a common use of init to change run states. As such it should +probably live not in /lib. I think that /etc/init is a better place. Not +that it matters all that much when source for everything is to be the norm. +If I think that my way is better, why then, I'll just go change things. That's +the code of the West :-) +-- +Mike Murphy mrm@Optigfx.COM ucsd!optigfx!mrm +1 619 292 6060 x 265 +Optigraphics Corporation 9339 Carroll Park Drive San Diego, CA 92121 +The opinion(s) expressed above are mine and not those of my employer. + +From linux-standards-request@banjo.concert.net Fri Feb 21 14:31:07 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <26767-0@banjo.concert.net>; Fri, 21 Feb 1992 14:30:32 -0500 +Received: from relay2.UU.NET by jazz.concert.net (5.59/tas-concert/6-19-91) + id AA02707; Fri, 21 Feb 92 14:30:29 -0500 +Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET + with SMTP (5.61/UUNET-internet-primary) id AA18265; + Fri, 21 Feb 92 14:30:29 -0500 +Received: from optigfx.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) + id 142908.25885; Fri, 21 Feb 1992 14:29:08 EST +Received: from optisun17.optigfx.com by optigfx.com (4.1/SMI-4.1) id AA28059; + Fri, 21 Feb 92 10:10:58 PST +Received: by optisun17.optigfx.com (4.1/SMI-4.1) id AA05315; + Fri, 21 Feb 92 10:09:15 PST +Date: Fri, 21 Feb 92 10:09:15 PST +From: optigfx!optisun17!mrm@uunet.UU.NET (Mike Murphy) +Message-Id: <9202211809.AA05315@optisun17.optigfx.com> +To: uunet!athena.mit.edu!tytso@uunet.UU.NET +Subject: Re: Seen in comp.os.minix +Cc: linux-standards@concert.net + +You hide all the definitions for weirdo disks and such under /dev/dsk/ and +/dev/rdsk/, and wierdo tapes under /dev/mt/ and then link the /dev/hd0 +(or equivalent) to the /dev/dsk/0s4 (or equivalent) and link /dev/tape +to /dev/mt/9tr1600snr (or some such where the major/minor lets me talk to +my 9track1600bpi in non-rewind streaming modeu. Then you can to refer to +/dev/tape instead of having to diddle with mknod when you do things like +change to a cartridge tape drive. Make sense? +-- +Mike Murphy mrm@Optigfx.COM ucsd!optigfx!mrm +1 619 292 6060 x 265 +Optigraphics Corporation 9339 Carroll Park Drive San Diego, CA 92121 +The opinion(s) expressed above are mine and not those of my employer. + +From linux-standards-request@banjo.concert.net Fri Feb 21 20:21:21 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <08476-0@banjo.concert.net>; Fri, 21 Feb 1992 20:21:07 -0500 +Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com) + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA05229; + Fri, 21 Feb 92 20:21:03 -0500 +Received: by dg-rtp.dg.com (5.4/dg-rtp-proto) id AA16586; + Fri, 21 Feb 1992 20:20:51 -0500 +Received: by ponds.UUCP (smail2.5) id AA09789; 21 Feb 92 06:37:13 EST (Fri) +To: dg-rtp!banjo.concert.net!linux-standards-request@concert.net, + dws@engr.uark.edu +Subject: re: Seen in comp.os.minix +Cc: linux-standards@concert.net +Message-Id: <9202210637.AA09785@ponds.UUCP> +Date: 21 Feb 92 06:37:13 EST (Fri) +From: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers) + +> > I completely agree with having just admin. files in /etc and executables in +> > /usr/etc. +> +> Ok, put init in /usr/etc, and make sure /usr is mounted just before you +> exec it. +> +> Minor problem. +> + +I don't agree here, putting init in /usr/etc and "making sure /usr is +mounted" is not a "minor problem", especially considering a networked +environment (in some newer UNIXs /usr isn't actually on a local drive, +/usr/xxxx where xxxxx is anything but "local" isn't on a local drive.) + +In my opinion, SUN, et. al. have gone a long way in solving these issues +with the /var directory, etc... we should *seriously* look at what they +did, why they did it, before we re-invent the wheel... + + - Dave Rivers - + +From linux-standards-request@banjo.concert.net Thu Feb 27 10:06:58 1992 +Return-Path: +Received: from banjo.concert.net by banjo.concert.net + id <22771-0@banjo.concert.net>; Thu, 27 Feb 1992 10:06:23 -0500 +Subject: Third Draft Soon. +To: linux-standards@banjo.concert.net +Date: Thu, 27 Feb 92 10:06:20 EST +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@banjo.concert.net + +I must regret my heavy work-load cutting into my Linux activities. I will +shortly be distributing the THIRD draft, including changes to allow +'administrative binaries' to live in /etc, and 'binaries required to support +programs residing in /usr/bin' to reside in /usr/lib. + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux-standards-request@banjo.concert.net Fri Feb 28 07:08:12 1992 +Return-Path: +Received: from daimi.aau.dk by banjo.concert.net with SMTP (PP) + id <24585-0@banjo.concert.net>; Fri, 28 Feb 1992 06:25:59 -0500 +Received: from bentley.daimi.aau.dk by daimi.aau.dk + with SMTP (5.61++/IDA-1.2.8) id AA09668; + Fri, 28 Feb 92 12:25:47 +0100 +Received: by bentley.daimi.aau.dk (5.64/1.34) id AA14724; + Fri, 28 Feb 92 12:25:44 +0100 +Date: Fri, 28 Feb 92 12:25:44 +0100 +From: tthorn@daimi.aau.dk +Message-Id: <9202281125.AA14724@bentley.daimi.aau.dk> +To: abc@banjo.concert.net +Cc: linux-standards@banjo.concert.net +In-Reply-To: Alan B Clegg's message of Thu, 27 Feb 92 10:06:20 EST <9202271507.AA12216@daimi.aau.dk> +Subject: Third Draft Soon. + +Good!! This ought to be acceptable to everybody. + +/Tommy + +From linux-standards-request@banjo.concert.net Tue Mar 3 13:02:51 1992 +Return-Path: +Received: from nec-gw.nec.com by banjo.concert.net with SMTP (PP) + id <02528-0@banjo.concert.net>; Tue, 3 Mar 1992 13:02:37 -0500 +Received: by nec-gw.nec.com (5.61+++/YDL1.7-911107.16) + id AA20546(nec-gw.nec.com ); Tue, 3 Mar 92 10:12:35 -0800 +Received: by sj.nec.com (5.61+++/901019) id AA10636(netkeeper.sj.nec.com); + Tue, 3 Mar 92 10:12:32 -0800 +Received: from necscc.cl.nec.co.jp + by necspl.ccs.mt.nec.co.jp (4.0/6.4J.6-NEC021) id AA17682; + Mon, 2 Mar 92 11:29:54 JST +Received: from nsis.cl.nec.co.jp by necscc.cl.nec.co.jp (4.1/6.4J.6) id AA20897; + Mon, 2 Mar 92 11:31:51 JST +Received: by nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-MX1.20) id AA24730; + Mon, 2 Mar 92 11:29:47 JST +Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.0) id AA04174; + Mon, 2 Mar 92 11:28:25 JST +Date: Mon, 2 Mar 92 11:28:25 JST +From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) +Return-Path: +Message-Id: <9203020228.AA04174@silk1.nsis.cl.nec.co.jp> +To: linux-standards@banjo.concert.net +Subject: International display + + Just for your information. A group of us in Japan are planning to port Linux +to the more popular machines here. This will mean rewriting the drivers, +etc. If anyone has any ideas for an international console device driver, let +me know. At the moment, we are thinking of supporting EUC or JIS-7. + +nick + + +From Linux-standards-request@banjo.concert.net Wed Mar 4 02:29:20 1992 +Return-Path: +Received: from van-bc.wimsey.bc.ca by banjo.concert.net with SMTP (PP) + id <03463-0@banjo.concert.net>; Wed, 4 Mar 1992 02:28:47 -0500 +Received: by wimsey.bc.ca (/\==/\ Smail3.1.22.1 #22.7 sendmail) + id ; Tue, 3 Mar 92 23:28 PST +Message-Id: +From: stewart@wimsey.bc.ca (Jim Stewart) +Subject: Some Concerns +To: Linux-standards@banjo.concert.net +Date: Tue, 3 Mar 92 23:28:37 PST +X-Mailer: ELM [version 2.3 PL11] + + +I have a couple of concerns about the implementation of ps on +tsx-11.mit.edu. The work done is of high quality, and returns +handy information, *however*: + +1) The use of a ps specific database of kernel symbols is IMHO a mistake. + I prefer to use nlist and the system image. I do not intend to boot + from floppy forever, and if the image is available I vote that it be + used. + +2) The number of patches to the kernel required to support instrumentation + for this command scares me. I am uncomfortable with the notion of adding + individual fields to to the structures in an ad hoc fashion. + +With respect to the first point: + + + I think that an official decision must be made soon as to the name + of the system image in the root directory. + + + Second, the default for the linux Makefile build should be changed + to NOT strip symbols. + + + Third, and nlist(3) should be added to libc.a in the standard + distribution. + +With respect to the second point: + + + A small collection of standard structures can be defined for + performance metering: + + - struct vmmeter {...} and for memory + - struct psmeter {...} and for tasks + - struct iometer {...} and for io + - ? + + + The goal of this work should be to localize changes to the kernel + for performance monitoring, with an eye to adding both conditional + inclusion and syscall access to this information. + +If we do not do something about this now, we can expect a proliferation +of incompatible "sbin" utilities that will be so patch level dependent +as to be of little use to the general community. + +js + +From Linux-standards-request@banjo.concert.net Sun Mar 8 04:15:42 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <10504-0@banjo.concert.net>; Sun, 8 Mar 1992 04:15:23 -0500 +Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP + id <15825-0@sun2.nsfnet-relay.ac.uk>; Sat, 7 Mar 1992 21:44:39 +0000 +Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa01361; + 7 Mar 92 21:45 GMT +Date: Sat, 07 Mar 92 21:40:33 +0000 +From: Damiano Bolla +To: Linux-standards@banjo.concert.net +Subject: Small suggestion.... :-) + +I spent a bit of time porting stuff this weekend. The various problems I +had suggested to me that there must be a way to make things easyer. + +What I mean is that all people around is sayng: This is missing, this is +not standard SYSV, this has to be added. + +To who should this be directed ? +To Linux ? +To the linux-standards ? + +Who decides if /unix is /unix or /linux ? +It is useful to know it so you can count on something when you start coding ! + +Damiano + +P.S. When will the tree structure be published ? + Can /unix be put in the tree structure ? + ( I am against of reinventing new names for old things ) + +From Linux-standards-request@banjo.concert.net Sun Mar 8 10:58:07 1992 +Return-Path: +Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP) + id <10703-0@banjo.concert.net>; Sun, 8 Mar 1992 10:57:48 -0500 +Received: by sumax.seattleu.edu id AA02939 (5.65a/IDA-1.4.2 + for Linux-standards@banjo.concert.net); Sun, 8 Mar 92 08:00:48 -0800 +Date: Sun, 8 Mar 92 08:00:48 -0800 +From: Chuck Boyer +Message-Id: <9203081600.AA02939@sumax.seattleu.edu> +To: Linux-standards@banjo.concert.net, db1@ukc.ac.uk +Subject: Re: Small suggestion.... :-) + +Linus himself should decide what basic tree structure is used in Linux +and let all others restructure according to their needs. When they publish +a 'port' of some program they should designate what tree structure they +use in a readme file. +chuck + +From Linux-standards-request@banjo.concert.net Sun Mar 8 11:29:26 1992 +Return-Path: +Received: from kruuna.Helsinki.FI by banjo.concert.net with SMTP (PP) + id <10739-0@banjo.concert.net>; Sun, 8 Mar 1992 11:29:10 -0500 +Received: by kruuna.helsinki.fi id AA22422 (5.65c/IDA-1.4.4 + for Linux-standards@banjo.concert.net); + Sun, 8 Mar 1992 18:29:04 +0200 +Date: Sun, 8 Mar 1992 18:29:04 +0200 +From: Linus Benedict Torvalds +Message-Id: <199203081629.AA22422@kruuna.helsinki.fi> +X-Mailer: Mail User's Shell (7.1.1 5/02/90) +To: Linux-standards@banjo.concert.net +Subject: Re: Small suggestion.... :-) + +Chuck Boyer: "Re: Small suggestion.... :-)" (Mar 8, 8:00): +> Linus himself should decide what basic tree structure is used in Linux +> and let all others restructure according to their needs. When they publish +> a 'port' of some program they should designate what tree structure they +> use in a readme file. + +Thanks for the vote of confidence, but I feel that this kind of standard +is something I need not decide: the last draft I saw looked nice, and as +long as it's simple and relatively standard, I'll go along. The +discussion on the directory structure seemed to be well enough thought +out, and all the points I ever wanted to say came up in mails by others. +There was a lot of "noise", but the result looked simple and workable. +I don't see why that couldn't be accepted as "final" - if there are +major problems we can always make changes later, but I wouldn't think +that would be needed. + +I'm also more than happy enough to see that people are ready to engage +in this kind of discussion: I'm mostly interested in the kernel proper, +and I feel user-level (even if the user is root) things are better +decided by people who use the system. I'd rather just make the /really/ +low-level things available: the kernel and the root-image. If the rest +of the distribution can be organized some other way (ABC-release), I'll +be very happy indeed. + + Linus + +From Linux-standards-request@banjo.concert.net Sun Mar 8 11:50:31 1992 +Return-Path: +Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP) + id <10775-0@banjo.concert.net>; Sun, 8 Mar 1992 11:50:15 -0500 +Received: by sumax.seattleu.edu id AA04346 (5.65a/IDA-1.4.2 + for Linux-standards@banjo.concert.net); Sun, 8 Mar 92 08:53:17 -0800 +Date: Sun, 8 Mar 92 08:53:17 -0800 +From: Chuck Boyer +Message-Id: <9203081653.AA04346@sumax.seattleu.edu> +To: Linux-standards@banjo.concert.net, torvalds@cc.helsinki.fi +Subject: Re: Small suggestion.... :-) + +Okay. I/we are so grateful for your kernel/root-image Linux flavour of +unix for our hot new 386/486 boxes, all of the great work. Thankyou. +Okay for the 'standard' of the tree structure having been set and published +by others. Where is it, by the way? Will it be published in the FAQ, with +the new 13 version of Linux (out soon), or where? + +I, by the way, am working on a text file (plain text with tabs, no +nroff, troff, Tex, etc.) on explaining for 'beginners' just exactly what +everything is pertaining to Linux on the ftp site tsx-11. + +INSTALL +>these are the 1) Linux operating system itself; a) bootimage/version#, +>and b) rootimage/version#, 2) rawrite (program to be used in DOS environ- +>ment to transfer root/boot image files to floppies, 3) edpart, pdisk +>(hard-disk partition programs used in DOS environment to set up partitions). + + bootimage-0.12.Z + partition-programs/ + rawrite.c + rawrite.doc + rawrite.exe + rootimage-0.12.Z + +INSTALL/partition-programs: + edpart.arc + edpart.doc + pdisk.arc + pdisk.doc +-----------------------etc.... + +I am willing to go through the whole thing and set it up like this. +The reasoning is that I, and perhaps others as well, get very tired +typing out the same answers/responses over and over again. Actually, +I need to hand hold a friend here at sumax and I'd like to make it +available to the net. +Any suggestions? +chuck + +From Linux-standards-request@banjo.concert.net Sun Mar 8 22:55:21 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <11241-0@banjo.concert.net>; Sun, 8 Mar 1992 22:55:03 -0500 +Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP + id <2227-0@sun2.nsfnet-relay.ac.uk>; Mon, 9 Mar 1992 01:12:26 +0000 +Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa02418; + 8 Mar 92 18:34 GMT +Date: Sun, 08 Mar 92 18:31:40 +0000 +From: Damiano Bolla +To: Linux-standards@banjo.concert.net +Subject: Re: Small suggestion (boyer) + +Ok, Then when there is something missing +( some library function or some include non "standard" ) +should we send a request to him ? + +During my porting I found some bits bissing. Should I mail to +Linux or would it be better to have an organization where one +person is responsabile for include, one for the libraryes, +one for the kernel ( Linux ).. and so on... + +Anyway, when is the new version of linux going to be released ? + +Damiano + + +From linux-standards-request@banjo.concert.net Mon Mar 9 00:30:10 1992 +Return-Path: +Received: from nec-gw.nec.com by banjo.concert.net with SMTP (PP) + id <11302-0@banjo.concert.net>; Mon, 9 Mar 1992 00:29:54 -0500 +Received: by nec-gw.nec.com (5.61+++/YDL1.7-911107.16) + id AA18023(nec-gw.nec.com ); Sun, 8 Mar 92 21:40:49 -0800 +Received: by sj.nec.com (5.61+++/901019) id AA27743(netkeeper.sj.nec.com); + Sun, 8 Mar 92 21:40:42 -0800 +Received: from necscc.cl.nec.co.jp + by necspl.ccs.mt.nec.co.jp (4.0/6.4J.6-NEC021) id AA12640; + Mon, 9 Mar 92 14:29:32 JST +Received: from nsis.cl.nec.co.jp by necscc.cl.nec.co.jp (4.1/6.4J.6) id AA06482; + Mon, 9 Mar 92 14:28:33 JST +Received: by nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-MX1.20) id AA11404; + Mon, 9 Mar 92 14:29:50 JST +Received: by silk1.nsis.cl.nec.co.jp (4.1/6.4J.6-nsis-ksp-4.0) id AA08408; + Mon, 9 Mar 92 14:28:26 JST +Date: Mon, 9 Mar 92 14:28:26 JST +From: nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) +Return-Path: +Message-Id: <9203090528.AA08408@silk1.nsis.cl.nec.co.jp> +To: linux-standards@banjo.concert.net +Subject: ETA & standards + +I too, would like to know when the ETA for the +next version is. The group who want to port +Linux to the Japanese computers are waiting for +version 0.13 before starting. Also, is anyone +interested in creating an "international" +Linux standard? + +nick + + +From linux-standards-request@banjo.concert.net Mon Mar 9 09:25:30 1992 +Return-Path: +Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP) + id <12057-0@banjo.concert.net>; Mon, 9 Mar 1992 09:25:13 -0500 +Received: by sumax.seattleu.edu id AA09338 (5.65a/IDA-1.4.2 + for linux-standards@banjo.concert.net); Mon, 9 Mar 92 06:28:16 -0800 +Date: Mon, 9 Mar 92 06:28:16 -0800 +From: Chuck Boyer +Message-Id: <9203091428.AA09338@sumax.seattleu.edu> +To: linux-standards@banjo.concert.net, nick@nsis.cl.nec.co.jp +Subject: Re: ETA & standards + +BTW, when are the standards going to be posted, or when are we going to +be reminded of where they are? +chuck + +From linux-standards-request@banjo.concert.net Mon Mar 9 09:35:54 1992 +Return-Path: +Received: from banjo.concert.net by banjo.concert.net + id <12110-0@banjo.concert.net>; Mon, 9 Mar 1992 09:35:39 -0500 +Subject: Revision 1.0 posted to alt.os.linux +To: linux-standards@banjo.concert.net +Date: Mon, 9 Mar 92 9:35:37 EST +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@banjo.concert.net + +Revision 1.0 (following Draft 2) of the Directory Structure document has been +posted to alt.os.linux. + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux-standards-request@banjo.concert.net Mon Mar 9 11:10:20 1992 +Return-Path: +Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP) + id <14772-0@banjo.concert.net>; Mon, 9 Mar 1992 11:09:01 -0500 +Received: by sumax.seattleu.edu id AA02986 (5.65a/IDA-1.4.2 + for linux-standards@banjo.concert.net); Mon, 9 Mar 92 08:12:00 -0800 +Date: Mon, 9 Mar 92 08:12:00 -0800 +From: Chuck Boyer +Message-Id: <9203091612.AA02986@sumax.seattleu.edu> +To: abc@banjo.concert.net, linux-standards@banjo.concert.net +Subject: Re: Revision 1.0 posted to alt.os.linux + +Revision 1.0 (following Draft 2) of the Directory Structure document has been +posted to alt.os.linux. + +thanks, I was asking Linux yesterday and he didn't know where they were +either. +chuck + +From linux-standards-request@banjo.concert.net Tue Mar 10 14:29:34 1992 +Return-Path: +Received: from banjo.concert.net by banjo.concert.net + id <18798-0@banjo.concert.net>; Tue, 10 Mar 1992 14:29:03 -0500 +Subject: Greetings, and welcome to phase 2. +To: linux-standards@banjo.concert.net +Date: Tue, 10 Mar 92 14:28:56 EST +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@banjo.concert.net + +Well, with the publication of the File Systems Document, the Standards Mailing +list has grown by about 15 people today alone. + +Since there is no current discussion, I will start some. + +I am preparing the ABC-Release of 0.95, and am looking for the *LATEST* +versions of the following: + + usr.bin sources [Are there changes since *.12?] + usr.lib sources " + library sources " + Compiler (1.40/2.00) with and without FP support. + Gnu Utilities (Compiled with latest libraries/compiler) + SCSI drive for AHA-1542 that works under .95 (no, I have not tested + the old one yet, since I don't have + the latest compiler yet) + +I have looked at the MIT and funet archives, and they are in a bad state of +repair, with many versions of the same things and many patches that don't +quite fit the current version, etc... + +I have also restarted the banjo FTP archive mirrors, so if banjo.concert.net +is closer to you than to any of the other archives, you might want to check +here... + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux-standards-request@banjo.concert.net Wed Mar 11 16:41:56 1992 +Return-Path: +Received: from dragonfly.wri.com by banjo.concert.net with SMTP (PP) + id <24185-0@banjo.concert.net>; Wed, 11 Mar 1992 16:41:42 -0500 +Received: from fishy.wri.com by dragonfly.wri.com with SMTP + id AA25631 (5.65c/IDA-1.4.4 for ); + Wed, 11 Mar 1992 15:41:38 -0600 +Return-Path: +From: dugan@wri.com +Message-Id: <9203112128.AA12169@fishy.wri.com> +Subject: ABC Release +To: linux-standards@banjo.concert.net +Date: Wed, 11 Mar 92 15:28:02 CST +In-Reply-To: <9203101950.AA04738@archimedes.math.uiuc.edu>; from "Alan B Clegg" at Mar 10, 92 2:28 pm +X-Mailer: ELM [version 2.3 PL11] + +I am all for this, it is hard to know what the most current +versions of things are, and is also a pain to have to get 500 +different files to make a complete Linux system. + +It would be nice to have a listing of the latest versions of each +part of Linux. Also, has anyone tried to implement mail for Linux +at all? especically uucp & local mail? If not does anyone know of +any possible source to try to port? + +Jon +-- +Jon Dugan (dugan@wri.com) - SQA Group +Wolfram Research, Inc. 217/398-0700 + +From linux-standards-request@banjo.concert.net Thu Mar 12 07:10:41 1992 +Return-Path: +Received: from jazz.concert.net by banjo.concert.net with SMTP (PP) + id <25326-0@banjo.concert.net>; Thu, 12 Mar 1992 07:10:23 -0500 +Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com) + by jazz.concert.net (5.59/tas-concert/6-19-91) id AA25900; + Thu, 12 Mar 92 07:10:16 -0500 +Received: by dg-rtp.dg.com (5.4/dg-rtp-proto) id AA04920; + Thu, 12 Mar 1992 07:10:14 -0500 +Received: by ponds.UUCP (smail2.5) id AA02757; 12 Mar 92 07:04:48 EST (Thu) +To: linux-standards@concert.net +Subject: Re: uucp. +Message-Id: <9203120704.AA02753@ponds.UUCP> +Date: 12 Mar 92 07:04:48 EST (Thu) +From: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers) + + +I have been working on taylor-uucp for some time, and have been +getting closer-and-closer. + +I can get a chat going, and the first shere=.... but the conversation +eventually locks up. + +But - I have been working with version 0.12; and haven't had time +to try 0.95 - which could possibly be better. + + - Dave Rivers - + (rivers@ponds.uucp) + +From linux-standards-request@banjo.concert.net Sat Mar 14 00:37:29 1992 +Return-Path: +Received: from JARTHUR.CLAREMONT.EDU by banjo.concert.net with SMTP (PP) + id <14789-0@banjo.concert.net>; Sat, 14 Mar 1992 00:36:57 -0500 +Date: Fri, 13 Mar 92 21:34:55 PST +From: "Jim Winstead Jr." +To: linux-standards@banjo.concert.net +Subject: Linux v0.95a and the ABC-Release + + +The release of Linux v0.95a, which is expected sometime next week, +will be handled a little differently than past releases. After a +little bit of discussion with Linus, I have agreed to take over the +distribution of the root-system diskette. + +What does this mean? Well, for one thing, the ABC-Release may become +obsolete real fast, since I have spent a good deal of time +restructuring the root floppy towards the released Linux Directory +Structure Standard (I don't believe this is the original name, but +it's what I have since dubbed it - I think it was called the Linux +File System Standard, which could cause possible confusion once a +Linux File System is defined to replace the current Minix one. +Besides, it really defines the Directory Structure, not the File +System.) + +I have spent some time pouring through the back archives of the +standards mailing list, and the LDS-Standard, and have a few questions +for the members of this esteemed committee. (: + +1) Has a place been decided for init, update, swapon, mkfs, + mknod, and other such administrative utilities? From all the + indications I've seen, /etc looks like the place to put them. + + What about other daemons? (cron comes to mind, especially.) + + /usr/etc is WRONG! /etc/rc is started by init. /usr may be + mounted in rc. How can /usr/etc/init run /rc if /usr hasn't + been mounted yet? + +2) I've renamed agetty to getty. This fits in with keeping the + standard names for the standard unix utilites, even if they've + been gleaned from sources that used different names to avoid + conflict. (i.e. the GNU stuff.) + +3) Where should programs like doshell and setterm go? These are + Linux-specific, and my reading of the LDS-Standard has them + fitting into /usr/bin/local, which seems very odd. Would they + make more sense in /usr/bin? + +4) Something that will be on the root diskette, and may warrant + mention in the LDS-Standard is a directory called /INSTALL + where some documentation and installation scripts will go. + Is there a better place for this? (Perhaps something special + under /usr/man? /usr/man/INSTALL?) + +5) Do we want to see a /var tree? I like the idea, personally. + +6) Here is the current tree structure on my root disk: + + + .--------+-dev + +-usr------+-bin + | +-adm + | +-etc + | +-spool + | +-local----+-bin + | | +-etc + | | +-lib + | | +-man + | | +-src + | +-lib + | +-man + | +-include + | +-src------+-bin + | | +-lib + | | +-linux + | | +-usr.bin + | | +-usr.lib + | +-tmp + +-bin + +-etc + +-tmp + +-mnt + +-home + +-lib + +-INSTALL + + As you might have guessed, a large part of this is just tree. + /usr/local is all empty, /usr/bin has very few files in it, and + /mnt, /lib, /home, and /tmp are empty. + + The bulk of the files are in /bin, with all the devices in + /dev, obviously. /etc also contains some barebones config + files. (passwd, profile, rc, etc.) + +7) tar and compress are in /bin, since they are necessary to the + restoring of a toasted partition. (gotta get the backups + somewhere!) Make sense to everyone? + +*) What do people think of a few shell scripts, such as 'mktree', + 'mkdev', 'install', etc, as part of the /INSTALL directory? + + mktree would create a blank directory tree on a clean + partition, mkdev would create the standard devices (similar to + the MAKEDEV suggestion made by someone earlier.) and install + would copy over the files from the root floppy to a partition + mounted on /mnt (or specified, if the root floppy is mounted as + /mnt instead of being booted from.) + + If anyone is willing to write these, go ahead and send + something to me. Be forewarned that it will probably be + hacked up a fair bit to fit with what I already have. + +I'll cut myself off here, to collect my thoughts some more and give +you plenty of time for feedback. I expect the release of 0.95a by the +end of next week at the absolute latest, with early next week as more +likely, so go ahead and flood my mailbox. + +(Also, at least until Monday, cc: your messages to the Linux Standards +list concering this to me as well, in case abc doesn't get around to +adding me to the list until next Monday.) +-- +Jim Winstead Jr. (CSci '95) | "Catch a fish!" +Harvey Mudd College | -Geddy Lee, +jwinstea@jarthur.Claremont.EDU | San Diego Sports Arena +Disclaimer: Mine, not theirs! | January 20, 1992 + +From linux-standards-request@banjo.concert.net Sat Mar 14 01:22:04 1992 +Return-Path: +Received: from TSX-11.MIT.EDU by banjo.concert.net with SMTP (PP) + id <14871-0@banjo.concert.net>; Sat, 14 Mar 1992 01:21:38 -0500 +Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA01337; + Sat, 14 Mar 92 01:21:27 -0500 +Date: Sat, 14 Mar 92 01:21:27 -0500 +From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) +Message-Id: <9203140621.AA01337@tsx-11.MIT.EDU> +To: "Jim Winstead Jr." +Cc: linux-standards@banjo.concert.net +In-Reply-To: jwinstea@jarthur.Claremont.EDU's message of Fri, 13 Mar 92 21:34:55 PST, <9203140537.AA26470@Athena.MIT.EDU> +Subject: Re: Linux v0.95a and the ABC-Release +Reply-To: tytso@athena.mit.edu +Address: 1 Amherst St., Cambridge, MA 02139 +Phone: (617) 253-8091 + +Well, your comments look on target to me, as far as the structure on the +Root-system diskette. At least as far as my imaging of what the ABC +release is all about, I don't think that it necessarily obsoletes it. +My vision of the ABC-release is that it would be a large, comprehensive +release of binaries and sources for Linux, so we're talking about a file +hierarchy much larger than the 1.2 meg root image floppy. The keeper of +this release would worry about getting the latest sources from authors, +making sure that utilities such as "ps" work with the latest kernel that +has been released, etc., etc. Of course, that's my vision only. You +should ask other people, in particular Alan Clegg (abc@concert.net) if +that's what they had in mind when they saw the words "ABC Release". + + - Ted + +From linux-standards-request@banjo.concert.net Sat Mar 14 01:47:27 1992 +Return-Path: +Received: from JARTHUR.CLAREMONT.EDU by banjo.concert.net with SMTP (PP) + id <14917-0@banjo.concert.net>; Sat, 14 Mar 1992 01:47:10 -0500 +Date: Fri, 13 Mar 92 22:46:01 PST +From: "Jim Winstead Jr." +To: linux-standards@banjo.concert.net +Subject: A Small Correction + + +I said something silly about my root-floppy distribution "obsoleting" +the ABC-Release. This is a case of my brain skipping a few steps in +drawing some conclusions, and Ted (tytso) has straightened me out on +these. + +ABC-Release: Big distribution/organization of binaries and sources. + This would include much of the /usr tree. + +Linux 0.95a: Boot (by Linus) and Root (by me) floppies with the bare + minimum needed for installing Linux on a system. This + would include, besides the kernel, most of the stuff + you'd find on the root partition. (/bin, /etc, /dev, + and maybe in the future, /lib - shared libs!) + +(A note on the bit about shared libs - definitely not in 0.95a, since +gcc 2.0 with shared libs is still in the alpha stages. Once this hits +a release status, though, it will make the root floppy much easier to +fit things onto.) + +This is, of course, only how I see things. If you think differently, +feel free to tell me. (And remember, I'm not on the list yet, so cc: +things to me if they pertain to what I say, at least for the time +being.) +-- +Jim Winstead Jr. (CSci '95) | "Catch a fish!" +Harvey Mudd College | -Geddy Lee, +jwinstea@jarthur.Claremont.EDU | San Diego Sports Arena +Disclaimer: Mine, not theirs! | January 20, 1992 + +From linux-standards-request@banjo.concert.net Sun Mar 15 13:35:01 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <17422-2@banjo.concert.net>; Sun, 15 Mar 1992 13:34:26 -0500 +Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP + id <8024-0@sun2.nsfnet-relay.ac.uk>; Sat, 14 Mar 1992 18:12:22 +0000 +Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa26713; + 14 Mar 92 14:39 GMT +Date: Sat, 14 Mar 92 14:37:04 +0000 +From: Damiano Bolla +To: dugan@wri.com, linux-standards@banjo.concert.net +Subject: Re: ABC Release + +This is what I meant when I posted the news about having a different +subtree for each release. + +My idea is: +Put in each subtree the software the is NEW to that release ! +Ex: +The new kernel +The new cc or libraries +New include, programs + +So: If you want the latest stuff you get the latest release +and what you can't find in the latest release you may find in +the previous one. + +This is simpler and clearer than having +a lot of +newgcc, newkernel..... ando also keep the naming consistent ! + +If you like it please post a news :-) + +Damiano + +From linux-standards-request@banjo.concert.net Wed Mar 25 08:20:06 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <20181-0@banjo.concert.net>; Wed, 25 Mar 1992 08:03:35 -0500 +Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP + id <8831-0@sun2.nsfnet-relay.ac.uk>; Tue, 24 Mar 1992 13:40:51 +0000 +Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa02208; + 24 Mar 92 9:21 GMT +Date: Tue, 24 Mar 92 09:16:45 +0000 +From: Damiano Bolla +To: linux-standards@banjo.concert.net +Subject: Anybody willing to answer me ? + +In the news article where I posted the bug fix for the pipe read +I asked if making a symlink from /usr/src/linux/include/linux +to /usr/include/linux is a valid action. +Nobody answered me.... + +I also asked why there are two set of includes ( one in /usr/include +and one in /usr/src/linux/include ) and if it is possible to merge them +Again, no answer..... + +In another article I asked if anybody has any informations on the +Colorado QIC-10 tape drive or if anybody know where I can get any info. +No answer.... + +I begin to think that my university does not post my articles in the net + +Anyway, anybody is willing to answer to at least one of the above +questions ? + +Damiano + +From linux-standards-request@banjo.concert.net Wed Mar 25 08:51:36 1992 +Return-Path: +Received: from banjo.concert.net by banjo.concert.net + id <20369-0@banjo.concert.net>; Wed, 25 Mar 1992 08:50:56 -0500 +Subject: Re: Anybody willing to answer me ? +To: db1@ukc.ac.uk (Damiano Bolla) +Date: Wed, 25 Mar 92 8:50:53 EST +Cc: linux-standards@banjo.concert.net +In-Reply-To: ; from "Damiano Bolla" at Mar 24, 92 9:16 am +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@banjo.concert.net + +In previous mail, Damiano Bolla said something like: +> In the news article where I posted the bug fix for the pipe read +> I asked if making a symlink from /usr/src/linux/include/linux +> to /usr/include/linux is a valid action. +> Nobody answered me.... + +I will answer. Yes. It is valid, and I have done it on my system, and +expect the ABC Release of Linux .95a to have symlinks as well. + +BTW: Is anyone interested in contributing to the new release, or am I going +to have to get all the GNU stuff and do it myself? PLEASE HELP ME OUT! +We want Linux to be as easy as ABC, right? So-far I have recompiled bison, +gawk, and am working on the gnu fileutils (what was the resolution of the +missing ftruncate() call, anyway?) + +> In another article I asked if anybody has any informations on the +> Colorado QIC-10 tape drive or if anybody know where I can get any info. +> No answer.... + +Don't have any info on this... + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux-standards-request@banjo.concert.net Wed Mar 25 09:49:42 1992 +Return-Path: +Received: from FEDIX.FIE.COM by banjo.concert.net with SMTP (PP) + id <21237-0@banjo.concert.net>; Wed, 25 Mar 1992 09:49:20 -0500 +Received: by fedix.fie.com id AA00197 (5.65c/IDA-1.4.4 + for linux-standards@banjo.concert.net); Wed, 25 Mar 1992 14:50:00 GMT +Date: Wed, 25 Mar 1992 14:50:00 GMT +From: Mike Vore - W3CCV +Message-Id: <199203251450.AA00197@fedix.fie.com> +To: linux-standards@banjo.concert.net +Subject: Colorado Tape support + + +> In another article I asked if anybody has any informations on the +> Colorado QIC-10 tape drive or if anybody know where I can get any info. +> No answer.... + +I just subscribed to l-a-s so I didn't see your previous postings, but I +had Coherent on my system for about a year before turning to Linux. +Maybe some hackers can get thru to CMS, or crack their code. I've +talked with both Coherent (Mark Williams Co.) and to CMS about the +problem. They have both shrugged their sholders and pointed the blame +on the other. Hopefully - as I said - some hacker can break the code +and get the CMS tape drives running under Linux. +- mike + +------------------------------------------------- + Mike Vore, | Of course these are my thoughts, + SysManager | The company dosn't know what I'm + mvore@fedix.fie.com | thinking (or doing) + (voice) +1 (301)975-0103 | +------------------------------------------------- + + +From linux-standards-request@banjo.concert.net Wed Mar 25 10:05:22 1992 +Return-Path: +Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP) + id <21318-0@banjo.concert.net>; Wed, 25 Mar 1992 10:05:01 -0500 +Received: by sumax.seattleu.edu id AA12880 (5.65a/IDA-1.4.2 + for linux-standards@banjo.concert.net); Wed, 25 Mar 92 06:00:47 -0800 +Date: Wed, 25 Mar 92 06:00:47 -0800 +From: Chuck Boyer +Message-Id: <9203251400.AA12880@sumax.seattleu.edu> +To: db1@ukc.ac.uk, linux-standards@banjo.concert.net +Subject: Re: Anybody willing to answer me ? + +Damiano; +I am a beginner/intermediate, so... watch out for my answers... +but...; + +>In the news article where I posted the bug fix for the pipe read +>I asked if making a symlink from /usr/src/linux/include/linux +>to /usr/include/linux is a valid action. +>Nobody answered me.... + +I know that it is possible to make that kind of link, though I +do not know enough to say whether that is necessary. I did do +links in /usr/include to /usr/local/include for gcc stuff and +the compiler all of a sudden worked, it was hardcoded where +to find the stuff... + +>I also asked why there are two set of includes ( one in /usr/include +>and one in /usr/src/linux/include ) and if it is possible to merge them +>Again, no answer..... + +Same response. + +>In another article I asked if anybody has any informations on the +>Colorado QIC-10 tape drive or if anybody know where I can get any info. +>No answer.... + +Way beyond my knowledge. + +>I begin to think that my university does not post my articles in the net + +If this article response gets to you then you are okay. + +>Anyway, anybody is willing to answer to at least one of the above +>questions ? + +I am willing to answer anything that I can. + +>Damiano + +From linux-standards-request@banjo.concert.net Thu Mar 26 05:38:23 1992 +Return-Path: +Received: from daimi.aau.dk by banjo.concert.net with SMTP (PP) + id <24843-0@banjo.concert.net>; Thu, 26 Mar 1992 05:38:04 -0500 +Received: from austin.daimi.aau.dk by daimi.aau.dk with SMTP (5.61++/IDA-1.2.8) + id AA23079; Thu, 26 Mar 92 11:37:46 +0100 +Received: by austin.daimi.aau.dk (5.64/1.34) id AA19568; + Thu, 26 Mar 92 11:37:43 +0100 +Date: Thu, 26 Mar 92 11:37:43 +0100 +From: tthorn@daimi.aau.dk +Message-Id: <9203261037.AA19568@austin.daimi.aau.dk> +To: abc@banjo.concert.net +Cc: linux-standards@banjo.concert.net +In-Reply-To: Alan B Clegg's message of Wed, 25 Mar 92 8:50:53 EST <9203251443.AA20180@daimi.aau.dk> +Subject: Re: Anybody willing to answer me ? + + BTW: Is anyone interested in contributing to the new release, or am I going + to have to get all the GNU stuff and do it myself? PLEASE HELP ME OUT! + +I wanted to reply to your original message, but just didn't get around to it. +Yes, I think that the ABC-release is needed now more than ever. This mess +release without source cries out for the ABC-release. + +I'm still moving my adaptec to drew's scsi, so I haven't been able to help, +but I expect to compile RCS-5.6 and more, and upload binaries *AND* diffs, +original source(?) *AND* explainations on how and with which libraries +it was compiled. + +As the situation is now with gcc 2.0 and libraries (changing all the time), +we *really* need source and evt. diffs. + +/Tommy +PS: Sorry for all you using the adaptec, but it should be there RSN. + +From linux-standards-request@banjo.concert.net Thu Mar 26 09:22:30 1992 +Return-Path: +Received: from banjo.concert.net by banjo.concert.net + id <00307-0@banjo.concert.net>; Thu, 26 Mar 1992 09:22:03 -0500 +Subject: Re: ABC Release +To: dugan@wri.com +Date: Thu, 26 Mar 92 9:21:59 EST +Cc: linux-standards@banjo.concert.net +In-Reply-To: <9203112128.AA12169@fishy.wri.com>; from "dugan@wri.com" at Mar 11, 92 3:28 pm +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@banjo.concert.net + +In previous mail, dugan@wri.com said something like: + +[ Regarding the ABC Release of Linux .95a ] + +> I am all for this, it is hard to know what the most current +> versions of things are, and is also a pain to have to get 500 +> different files to make a complete Linux system. + +Yup. I have begun pulling down the sources *FROM PREP.AI.MIT.EDU* and +compiling, and I am *REALLY* impressed. Everything has been going relatively +well. I have the following packages completed: + + gawk, bison, make, shellutils, textutils, gnugo, gnuchess + +I am currently working on bash, but that is going slowly. I am waiting +with baited breath for the Adaptec SCSI drivers since I only have 40Meg of +IDE, and half a gig of SCSI.. I am running on *VERY* limited space right +now. I never realized just how big the GNU stuff really was... + +Anyone wanting to work on parts, please let me know so we can coordinate! + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux-standards-request@banjo.concert.net Sat Mar 28 07:31:33 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <09777-1@banjo.concert.net>; Sat, 28 Mar 1992 07:00:53 -0500 +Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP + id <22806-0@sun2.nsfnet-relay.ac.uk>; Sat, 28 Mar 1992 00:32:11 +0000 +Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa19546; + 27 Mar 92 15:59 GMT +Date: Fri, 27 Mar 92 15:52:20 +0000 +From: Damiano Bolla +To: linux-standards@banjo.concert.net +Subject: Thanks for the reply ! + +I want to thank everybody that answered me ! + +Sofar we know that +1) The include files in /usr/src/linux/include are the one + that are "important" and to be trusted. + +2) The news system jammed my last post :-( + +3) It is quite hard to find informations about the Colorado + QIC-10 ( the 120Mb tape ) + +5) I my past new I was posting a fix to the pipe read bug. + I sent the fix to linux. If he doesn't post a "better" version + of the fix I am going to try to code one :-) + +6) I am tryng to play with the VGA switching mode... + I mean I am tryng to swithch the VGA between graphics and + text mode. I managed to put into the kernel the minix mgr code + and it seems to work (got it working this morning) + I was wondering if somwbody else is playng with this suff..... + ( I am not using the BIOS I use direct VGA registers ) + + +Anyway. I think I will use the maillist instead of the news. It seems +more reliable. + +Damiano + +P.S. About the naming of the devices. +I think that the MOST important thing of all is to get the STANDARD +in such a vay that it is expandible. I don't really care what it is +as long I don't have to change names each time we have +More Pty +More Hd +More Tapes +More Serials +More VirtualConsols +More VgaFramebuffers +......... + +From linux-standards-request@banjo.concert.net Mon Mar 30 09:07:29 1992 +Return-Path: +Received: from banjo.concert.net by banjo.concert.net + id <13747-0@banjo.concert.net>; Mon, 30 Mar 1992 09:07:14 -0500 +Subject: Ok, we have been envoked. +To: linux-standards@banjo.concert.net +Date: Mon, 30 Mar 92 9:07:11 EST +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@banjo.concert.net + +erc@Apple.COM (Ed Carp) stated in a recent posting on device names: + +=I understand, and agree with you, but I think that the standards folks should +=just choose a standard, and then people can do the "ln -s" dance to make +=them whatever they want to. What the standards for the name are, in my +=opinion, irrelevent, since one can always link them to something else. +=You wouldn't want to actually RENAME them, of course, because someone +=will most certainly write software to conform to the standard that you +=just changed (and broke their software in the process). For example, +=/dev/tty should remain /dev/tty, but if someone doesn't like it, they can +=always "ln -s /dev/tty /dev/mytty" or some such. + +Ok, since the file system standard went over so well, I propose this +(open for discussion): + +/dev/wd -- Western Digital and related disk controllers +/dev/wd0 -- entire disk 0 +/dev/wd1 -- entire disk 1 +/dev/wd01 -- disk 0, partition 1 + --etc-- + +/dev/sd -- SCSI controllers +/dev/sd0 -- entire DEVICE 0 +/dev/sd01 -- DEVICE 0, LUN 1 +/dev/sd011 -- DEVICE 0, LUN 1, partition 1 [???] + --etc-- + +/dev/tty -- "your" tty +/dev/tty[a-d] -- com1 -> com4 [???] + [from SunOS] +/dev/ttyv[1-4] -- "virtual terminals" [???] +/dev/console -- /dev/ttyv1 [???] +/dev/ttyp[0-f] -- pseudo terminals +/dev/ttyq[0-f] pseudo terminals + +/dev/lp[ab] -- lpt1, lpt2 + +Ok, now... DISCUSS IT... Let's set a date of.. oh.. Wednesday the 1st of +April as the date for the first draft... + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux-standards-request@banjo.concert.net Mon Mar 30 10:51:26 1992 +Return-Path: +Received: from p.lanl.gov by banjo.concert.net with SMTP (PP) + id <14161-0@banjo.concert.net>; Mon, 30 Mar 1992 10:44:08 -0500 +Received: from zaphod.lanl.gov by p.lanl.gov (5.65/1.14) id AA06986; + Mon, 30 Mar 92 08:44:02 -0700 +Received: by zaphod.lanl.gov.lanl.gov (4.1/SMI-4.1) id AA00311; + Mon, 30 Mar 92 08:43:58 MST +Date: Mon, 30 Mar 92 08:43:58 MST +From: egdorf@zaphod.lanl.gov (Skip Egdorf) +Message-Id: <9203301543.AA00311@zaphod.lanl.gov.lanl.gov> +To: abc@banjo.concert.net +Cc: linux-standards@banjo.concert.net +In-Reply-To: Alan B Clegg's message of Mon, 30 Mar 92 9:07:11 EST <9203301411.AA05105@p.lanl.gov> +Subject: RE: Ok, we have been envoked. + + Ok, since the file system standard went over so well, I propose this + (open for discussion): + + /dev/wd -- Western Digital and related disk controllers + /dev/wd0 -- entire disk 0 + /dev/wd1 -- entire disk 1 + /dev/wd01 -- disk 0, partition 1 + --etc-- + + /dev/sd -- SCSI controllers + /dev/sd0 -- entire DEVICE 0 + /dev/sd01 -- DEVICE 0, LUN 1 + /dev/sd011 -- DEVICE 0, LUN 1, partition 1 [???] + +Typically, the "sd" or "wd" refers to a controller type. The 0, 1, ... is a +logical unit, and a letter "a" .. "h" is used to specify the logical partition. +so we would have (using 8 partitions) + +/dev/wd0a and /dev/sd0a +/dev/wd0b and /dev/sd0b +... +/dev/wd0h and /dev/sd0h + +with one of the partitions mapping the entire disk. Sun currently uses "c" for +this. + + /dev/tty[a-d] -- com1 -> com4 [???] + [from SunOS] +Or (more V7, BSDish) /dev/tty[0-4]. +Also used were /dev/tty[0123][0123456789abcdef] for things like 16-line +multiplexors. The first [0123] specified a controller and the [0-f] specified +line 0-15 of the device. + + Skip Egdorf + hwe@lanl.gov + +From linux-standards-request@banjo.concert.net Mon Mar 30 13:27:35 1992 +Return-Path: +Received: from JARTHUR.CLAREMONT.EDU by banjo.concert.net with SMTP (PP) + id <14533-0@banjo.concert.net>; Mon, 30 Mar 1992 12:37:21 -0500 +Date: Mon, 30 Mar 92 9:36:47 PST +From: "Jim Winstead Jr." +To: Alan B Clegg +cc: linux-standards@banjo.concert.net +Subject: Re: Ok, we have been envoked. + +>Ok, since the file system standard went over so well, I propose this +>(open for discussion): + +>/dev/wd -- Western Digital and related disk controllers +>/dev/wd0 -- entire disk 0 +>/dev/wd1 -- entire disk 1 +>/dev/wd01 -- disk 0, partition 1 + +Okay, what are 'Western Digitial and related controllers' as opposed +to anything else? Is this just 'standard' AT controllers? If so, I'd +recommened staying with /dev/hd*. + +>/dev/tty -- "your" tty +>/dev/tty[a-d] -- com1 -> com4 [???] + +I think it should be /dev/tty[0-3]. Most things should be kept +zero-based, I think, since it just makes things more consistent. + +>/dev/ttyv[1-4] -- "virtual terminals" [???] + +What would /dev/ttyv0 refer too? Another name for the current ttyv? Makes +sense to me. + +>/dev/console -- /dev/ttyv1 [???] +>/dev/ttyp[0-f] -- pseudo terminals +>/dev/ttyq[0-f] pseudo terminals + +These look reasonable, but leave room for expansion in the pseudo +terminals. (On my school computer, it runs from ttyp[0-9a-zA-z] and +stuff like that.) + +>/dev/lp[ab] -- lpt1, lpt2 + +Again, I'd have to vote for /dev/lp[01]. Makes more sense to me. +-- +Jim Winstead Jr. (CSci '95) | "Catch a fish!" +Harvey Mudd College | -Geddy Lee, +jwinstea@jarthur.Claremont.EDU | San Diego Sports Arena +Disclaimer: Mine, not theirs! | January 20, 1992 + +From linux-standards-request@banjo.concert.net Mon Mar 30 13:27:36 1992 +Return-Path: +Received: from bernina.ethz.ch by banjo.concert.net with SMTP (PP) + id <14594-0@banjo.concert.net>; Mon, 30 Mar 1992 13:17:39 -0500 +Received: from nessie by bernina.ethz.ch with SMTP inbound + id <17897-0@bernina.ethz.ch>; Mon, 30 Mar 1992 20:17:15 +0200 +Received: by nessie.cs.id.ethz.ch; Mon, 30 Mar 92 20:17:09 +0200 +Message-Id: <9203301817.AA25705@nessie.cs.id.ethz.ch> +From: almesber@nessie.cs.id.ethz.ch (Werner Almesberger) +Date: Mon, 30 Mar 1992 20:17:08 +0000 +In-Reply-To: Alan B Clegg "Ok, we have been envoked." (Mar 30, 9:07) +X-Mailer: Mail User's Shell (7.2.3 5/22/91) +To: linux-standards@banjo.concert.net +Subject: Re: Ok, we have been envoked. + +> /dev/ttyv[1-4] -- "virtual terminals" [???] +> /dev/console -- /dev/ttyv1 [???] + +I think, there should be a "current virtual console", maybe /dev/console +or /dev/ttyv ? + +> /dev/ttyp[0-f] -- pseudo terminals +> /dev/ttyq[0-f] pseudo terminals + +How about /dev/ttyp[0-9][0-9] and /dev/ttyq[0-9][0-9] ? Being limited to +16 ptys seems to be a bit odd in the days of iScreen and X. + +- Werner + +-- + _________________________________________________________________________ + / Werner Almesberger, ETH Zuerich, CH almesber@nessie.cs.id.ethz.ch / + / IFW A44 Tel. +41 1 254 7213 almesberger@rzvax.ethz.ch / +/_BITNET:_ALMESBER@CZHETH5A__HEPNET/CHADNET:_[20579::]57414::ALMESBERGER_/ + + +From linux-standards-request@banjo.concert.net Mon Mar 30 15:22:38 1992 +Return-Path: +Received: from daimi.aau.dk by banjo.concert.net with SMTP (PP) + id <14712-0@banjo.concert.net>; Mon, 30 Mar 1992 13:33:38 -0500 +Received: from ferrari.daimi.aau.dk by daimi.aau.dk + with SMTP (5.61++/IDA-1.2.8) id AA19609; + Mon, 30 Mar 92 20:33:27 +0200 +Received: by ferrari.daimi.aau.dk (5.64/1.34) id AA19616; + Mon, 30 Mar 92 20:33:26 +0200 +Date: Mon, 30 Mar 92 20:33:26 +0200 +From: tthorn@daimi.aau.dk +Message-Id: <9203301833.AA19616@ferrari.daimi.aau.dk> +To: abc@banjo.concert.net, linux-standards@banjo.concert.net +In-Reply-To: Skip Egdorf's message of Mon, 30 Mar 92 08:43:58 MST <9203301543.AA00311@zaphod.lanl.gov.lanl.gov> +Subject: RE: Ok, we have been envoked. + +Yes {wd,sd}[0-9][abcdefgh] seems right, but using c for the whole +disk is just a tad to strange for my liking. Would it be +to dangerous to just use {wd,sd}[0-9] ? + +Also, I disagree with Ed Carp (erc@Apple.COM). As we are still +very early in development, it sure better to change a bad design, +than to stick with it, just for sake of existing software. + +/Tommy + +From linux-standards-request@banjo.concert.net Mon Mar 30 15:23:49 1992 +Return-Path: +Received: from banjo.concert.net by banjo.concert.net + id <14733-0@banjo.concert.net>; Mon, 30 Mar 1992 13:36:02 -0500 +Subject: Re: Ok, we have been envoked. (fwd) +To: linux-standards@banjo.concert.net +Date: Mon, 30 Mar 92 13:35:58 EST +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@banjo.concert.net + + +> >/dev/wd -- Western Digital and related disk controllers + +> Okay, what are 'Western Digitial and related controllers' as opposed +> to anything else? Is this just 'standard' AT controllers? If so, I'd +> recommened staying with /dev/hd*. + +My machine has many more than just one type of 'hd', and like IBM getting away +with calling THEIR machine "THE PC", I don't like generic names like that. + +SCSI hard disks are also 'hd' in that case... I have both IDE (wd type) and +SCSI (adaptec 1542) drives on my system, and I need a way to tell the +difference. + +I like the idea of: + + /dev/wd{controller}{partition} + /dev/sd{controller}{partition} + +With controller being zero based, and using the berkeley lettering scheme +for the partitions: + + a-h, c being the "WHOLE THING", b being swap, etc etc.. + +Also, I am not opposed to zero basing everything. + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux-standards-request@banjo.concert.net Mon Mar 30 16:19:49 1992 +Return-Path: +Received: from cinelli.Physics.McGill.CA by banjo.concert.net with SMTP (PP) + id <15307-0@banjo.concert.net>; Mon, 30 Mar 1992 16:19:26 -0500 +Received: by cinelli.Physics.McGill.CA (5.57/Ultrix3.0-C) id AA09090; + Mon, 30 Mar 92 16:19:42 -0500 +Date: Mon, 30 Mar 92 16:19:42 -0500 +From: robbins@hep.physics.mcgill.ca (Steven Robbins) +Message-Id: <9203302119.AA09090@cinelli.Physics.McGill.CA> +To: linux-standards@banjo.concert.net +Subject: HD device names + + +Naming them /dev/wdxxx seems okay to me, but why on earth is wd0c the whole +disk? What's wrong with /dev/wd0 being all of disk zero, and /dev/wd0a being +the first partition, etc? + +Now, how about floppies? Using /dev/at0 &etc is far too arcane for me, so +I've created /dev/a1200 /dev/a720 /dev/b1440 and stuff like that. I realize +of course that some people have different configurations, but if only the +drives that existed on the system were in /dev, then a program could figure +out what kind of floppies were around. + +Actually, this reminds me of a question I had: in the directory standard, +I think it mentioned that the /dev directory should have ALL POSSIBLE devices, +and not just those that exist on the system. What's the rationale for this? +It would seem at first glance to be more advantageous the other way, so that +programs would know what kind of peripherals existed. + +Steve Z + +From linux-standards-request@banjo.concert.net Mon Mar 30 17:03:45 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <15534-0@banjo.concert.net>; Mon, 30 Mar 1992 17:03:20 -0500 +Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP + id <10691-0@sun2.nsfnet-relay.ac.uk>; Mon, 30 Mar 1992 12:37:57 +0100 +Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa26852; + 30 Mar 92 12:38 BST +Date: Mon, 30 Mar 92 12:38:16 +0100 +From: Damiano Bolla +To: linux-standards@banjo.concert.net + +I am sending this article here since my site has problems with the news. +If abc think that this article is worth to be posted it will be nice +if he could poste it in the net. + +Thanks to all +================================== + +Hello ! + +This article will give you a simple way to have text and graphics +using a VGA graphic adapter. + +Most of the ideas are taken from the mgr graphic interface for minix. + +The idea behind this simple patch is described in the following file: + +---------------------------------------------------------- + + + +VGAREGS(MS-DOS) Programmer's Manual (MS-DOS) VGAREGS(MS-DOS) + + +NAME + vgaregs - examine vga-adapter register values and generate an include + file for the MINIX/Linux screen driver. + +SYNOPSIS + vgaregs [ax[_bx] ...] [ > video.h ] + +DESCRIPTION + This program is intended to help you generating a proper include file for + the minix screen-driver if you are using a VGA display adapter. + + It uses the BIOS video interrupt 0x10 to switch to each one of the modes + specified at the command line. Register AX is loaded by the 'ax' value, + and, if 'bx' is also specified, this is loaded into the BX register. AX + (and BX) must be given as hexadecimal numbers without a leading '0x'. + + Vgaregs then reads the display adapter register values and tries to + determine the screen parameters. These parameters are printed on + standard output and should be redirected into a file. + + +OUTPUT FORMAT + Defines for the hercules-adapter in text and graphic modes are printed + first. + + The next define is + #define REGBASE 0x3B4 + if you have a monochrome monitor, and + #define REGBASE 0x3D4 + if you have a color monitor connected to your VGA adapter. + + For each video mode then definitions are printed in the form + + #define MODE_XX \ + `register values' + + and + + #define PARM_XX \ + PP( `video mode parameters' ) + + where `register values' is a list of the register values read from the + adapter (in the correct order as required by the screen driver), and + `screen parameters' is a guess of the screen parameters. The latter list + is not always correct, so you should compare this to your documentation. + 'XX' will be replaced by the corresponding command line string. (The + macro PP() is a hack for the C-preprocessor). + + The 'screen parameter' entries are in the following order: + + Physical Start address of video memory (short int) + Size of video memory in bytes (long int) + Pixels per line (short int) + Pixels per row (short int) + Number of bitplanes (short int) + always assumed to be 4 (16-color modes) + Interlace Flag (short int) + always set to 0 + Number of interlaced Pages (short int) + always set to 1 + Pagesize of interlaced pages (short int) + always set to 0 + + The first text mode and the first three graphic video modes given at the + command line should be those you actually want to use in the MINIX screen + driver. For these modes defines are added with names ?VGA_GRAF_PARMS, + ?VGA_GRAF_MODE, VGA_TEXT_PARMS and VGA_TEXT_MODE, for all other modes a + comment like /* This mode is not used */. + +EXAMPLE + vgaregs 3 10 12 29 37 > video.h + will generate an include file named video.h with definitions for textmode + (mode 3), 640x350 16 colors (mode 0x10), 640x480 16 colors (mode 0x12), + 800x600 16 colors (mode 0x29) and 1024x768 16 colors (mode 0x37) for the + 'OPTIMA/1024 plus' display adapter (TSENG 3000 chip). The names MODE_3, + MODE_10, MODE_12, MODE_29 and MODE_37 in the output file hold the + register values, PARM_3, PARM_10, PARM_12, PARM_29 and PARM_37 hold the + screen parameters. The values for PARM_37 are not determined correctly + by this program (See section BUGS). The generated include file will use + BIOS mode 3 as textmode, and modes 10, 12 and 29 as graphic modes. + +FURTHER HINTS + You can use vgaregs to collect information about ALL videomodes your + adapter can handle into one file. Only the first textmode encountered + and the first three graphic modes encountered are then used by the MINIX + screen driver. + You can then play with all these modes by simply changing some defines in + the generated file. + + Vgaregs uses the registers as the BIOS will set them. So it will + generate the same cursor shape (underline) as MS-DOS uses it by default. + If you like the MINIX block-type cursor, patch the MODE definition in the + output file for TEXT mode (entries 11 and 12 should be set to 0x00 and + 0x0F resp.). + Also worth patching are the color attribute registers (entries 25 - 40 in + the MODE definition), if you don't like the default colors. + +BUGS + Vgaregs is an MS-DOS program, as it uses the VGA-BIOS. + Vgaregs does not determine if you actually have a VGA adapter. + Vgaregs only knows about standard VGA registers, so probably 1024x768 + modes will never work (although modes up to 800x600 resolution usually + do). + Vgaregs (and also the screen driver) only works for VGA-modes with 16 + colors or less. + Vgaregs is ugly code. + +------------------------------------------------------------------------- +The above file describes the operations of the MSDOS vgaregs.exe program. +The all purpose of the program is to generate the vga.h file ! + +After that you can use it to create the new kernel using the following files. +The following one is the actual ioctl switch command... + +--------------------------------------------------------------------- + +/* Ident: fs/vga_ioctl.c + * Author : Damiano Bolla + * This implement the vga switching..... what a pain + * Based of the minix mgr manager + */ + +#include +#include +#include +#include +#include +#include +#include /* Definition of video modes */ +#include /* Structures used by the sys */ + +/* the next one is used to tell to the rest of the system where the + * Current vido map is and how long it is. + * NOTE: It is apointer to something ! ( when is set ) + */ + +struct scr_param *VideoParam = NULL; + +/* Some additional structure to keep the informations for switching */ +struct scr_defs + { + struct scr_param params; + char regs[60]; + }; + +/* + * Hack for the preprocessor (the most abused tool in the world?). + * Video parameters are defined as PP( .... ) in videodef.h + */ +#define PP(x1,x2,x3,x4,x5,x6,x7,x8) \ + x1, x2, x3, x4, x5, x6, x7, x8 + + +static struct scr_defs + Vga_Text = { { VGA_TEXT_PARMS }, { VGA_TEXT_MODE } }, + Vga_Graf = { { VGA_GRAF_PARMS }, { VGA_GRAF_MODE } }, +/* If you have the right values put them in in here..... */ + Svga_Graf = { { VGA_GRAF_PARMS }, { VGA_GRAF_MODE } }, + Evga_Graf = { { VGA_GRAF_PARMS }, { VGA_GRAF_MODE } }; + +extern int vga_mode( int mode ); + +int vga_ioctl(int dev, int cmd, int arg) + { + switch( cmd ) + { + case SCRSETMODE: + /* arg defines the requested vga status we want */ + vga_mode ( arg ); + return (0); + break; + case SCRGETP: + return (0); + break; + } + return EINVAL; + } + + +/* ================= VGA index register ports: ======================= */ +#define CRT_I 0x3D4 /* CRT Controller Index (0x3D4=color, 0x3B4=mono) */ +#define ATT_IW 0x3C0 /* Attribute Controller Index & Data Write Reg. */ +#define GRA_I 0x3CE /* Graphics Controller Index */ +#define SEQ_I 0x3C4 /* Sequencer Index */ + +/* VGA data register ports: */ +#define CRT_D 0x3D5 /* CRT Contr. Data Reg. (0x3D5=color, 0x3B5=mono) */ +#define ATT_R 0x3C1 /* Attribute Controller Data Read Register */ +#define GRA_D 0x3CF /* Graphics Controller Data Register */ +#define SEQ_D 0x3C5 /* Sequencer Data Register */ +#define MIS_R 0x3CC /* Misc Output Read Register */ +#define MIS_W 0x3C2 /* Misc Output Write Register */ +#define IS1_R 0x3DA /* Input Status Register 1 (Read only) + (0x3DA=color, 0x3BA=mono) */ +/* VGA indexes max counts: */ +#define CRT_C 24 /* 24 -CRT Controller Registers*/ +#define ATT_C 21 /* 21 -Attribute Controller Registers */ +#define GRA_C 9 /* 9 -Graphics Controller Registers */ +#define SEQ_C 5 /* 5 -Sequencer Registers */ +#define MIS_C 1 /* 1 -Misc Output Register */ + +/* VGA registers saving indexes */ +#define CRT 0 /* CRT Controller Registers start */ +#define ATT CRT+CRT_C /* Attribute Controller Registers start */ +#define GRA ATT+ATT_C /* Graphics Controller Registers -"- */ +#define SEQ GRA+GRA_C /* Sequencer Registers */ +#define MIS SEQ+SEQ_C /* General Registers */ +#define END MIS+MIS_C /* last */ + + +int vga_mode( int mode ) + { + static int curr_mode = VGA_TEXT; /* We know this is the initial */ + char *regs; /* pointer to new register values */ + int i; + +#ifndef ROM_CHAR_SET + static char vga_char_map[8192]; /* character map buffer */ + static map_initialized = 0; /* The map is not initalized */ +#endif + + /* Let'see if we need to switch..... */ + if ( curr_mode == mode ) return (0); + + switch(mode) + { + case VGA_TEXT: + regs = Vga_Text.regs; + VideoParam = &Vga_Text.params; + break; + case VGA_640x480: + regs = Vga_Graf.regs; + VideoParam = &Vga_Graf.params; + break; + case VGA_600x800: + regs = Svga_Graf.regs; + VideoParam = &Svga_Graf.params; + break; + case VGA_1024x768: + regs = Evga_Graf.regs; + VideoParam = &Evga_Graf.params; + break; + default: + return EINVAL; + break; + } + + /* Do we want to switch to text mode ??.. if so we need to restore */ + if ( (mode == VGA_TEXT) && (map_initialized == 1) ) + { + /* restore character map before setting TEXT mode */ + outb(0x04, GRA_I ); + outb(0x02, GRA_D ); /* select page 2 where to write map */ + +#ifndef ROM_CHAR_SET + (void) memcpy ((char *)0xA0000L, vga_char_map, sizeof (vga_char_map)); +#else + { + int i; + for (i=0; i<256; i++) + (void) memcpy ( (char *)(0xA0000L+(i+32)), (char *)(ROM_CHAR_SET+(i*16)), 16 ); + } +#endif + } + + /* ------------- set VGA registers to new values ---------------------*/ + inb(IS1_R); /* clear flip-flop */ + outb(0x00, ATT_IW ); /* Disable video */ + + outb(GRA_I,0x00); + outb(GRA_D,0x00); /* Set/Reset (graph) */ + + inb(IS1_R); /* clear flip-flop */ + outb(SEQ_I,0x00); + outb(SEQ_D,0x01); /* synchronous reset ON */ + +/* + * IMPORTANT NOTE: (speaking from experience!) + * BE SURE *** NOT *** TO ACCESS THE VIDEO MEMORY WHILE THE SEQUENCER IS OFF !!! + * THE CPU WILL WAIT FOREVER ON THE SCREEN ACCESS... + */ + outb(regs[MIS+0], MIS_W ); /* update misc output reg */ + + outb(0x1, SEQ_I ); + outb(regs[SEQ+1], SEQ_D ); /* update clocking mode */ + + for (i=2;i +#include + +#include +#include + +#include +#include + +#include /* To read write to screen */ + +extern int tty_read(unsigned minor,char * buf,int count,unsigned short flags); +extern int tty_write(unsigned minor,char * buf,int count); +extern int lp_write(unsigned minor,char *buf, int count); + +typedef (*crw_ptr)(int,unsigned,char *,int,off_t *,unsigned short); + +static int rw_ttyx(int rw,unsigned minor,char * buf,int count,off_t * pos, unsigned short flags) +{ + return ((rw==READ)?tty_read(minor,buf,count,flags): + tty_write(minor,buf,count)); +} + + +static int rw_lp(int rw,unsigned minor,char * buf,int count,off_t * pos) +{ + return ((rw==READ)? -EINVAL: + lp_write(minor,buf,count)); +} + +static int rw_tty(int rw,unsigned minor,char * buf,int count, off_t * pos, unsigned short flags) +{ + if (current->tty<0) + return -EPERM; + return rw_ttyx(rw,current->tty,buf,count,pos,flags); +} + +extern struct scr_param *VideoParam; + +static int rw_ram(int rw,char * buf, int count, off_t *pos) + { + /* This is supposed to access the VGA video ram..... */ + int i = *pos; + int base, limit; + + /* If we have an invalid pointer to the data we can't go on */ + if ( VideoParam == NULL ) return (-EIO); + + base = VideoParam->scr_base; + limit = base + VideoParam->scr_fbsize; + i+= base; + + while ( (count-- > 0) && (i 0) && (i 0 && i<65536) { + if (rw==READ) + put_fs_byte(inb(i),buf++); + else + outb(get_fs_byte(buf++),i); + i++; + } + i -= *pos; + *pos += i; + return i; +} + +static int rw_memory(int rw, unsigned minor, char * buf, int count, + off_t * pos, unsigned short flags) +{ + switch(minor) { + case 0: + return rw_ram(rw,buf,count,pos); + case 1: + return rw_mem(rw,buf,count,pos); + case 2: + return rw_kmem(rw,buf,count,pos); + case 3: + return (rw==READ)?0:count; /* rw_null */ + case 4: + return rw_port(rw,buf,count,pos); + default: + return -EIO; + } +} + +#define NRDEVS ((sizeof (crw_table))/(sizeof (crw_ptr))) + +static crw_ptr crw_table[]={ + NULL, /* nodev */ + rw_memory, /* /dev/mem etc */ + NULL, /* /dev/fd */ + NULL, /* /dev/hd */ + rw_ttyx, /* /dev/ttyx */ + rw_tty, /* /dev/tty */ + rw_lp, /* /dev/lp */ + NULL}; /* unnamed pipes */ + +int char_read(struct inode * inode, struct file * filp, char * buf, int count) +{ + unsigned int major,minor; + crw_ptr call_addr; + + major = MAJOR(inode->i_rdev); + minor = MINOR(inode->i_rdev); + if (major >= NRDEVS) + return -ENODEV; + if (!(call_addr = crw_table[major])) + return -ENODEV; + return call_addr(READ,minor,buf,count,&filp->f_pos,filp->f_flags); +} + +int char_write(struct inode * inode, struct file * filp, char * buf, int count) +{ + unsigned int major,minor; + crw_ptr call_addr; + + major = MAJOR(inode->i_rdev); + minor = MINOR(inode->i_rdev); + if (major >= NRDEVS) + return -ENODEV; + if (!(call_addr=crw_table[major])) + return -ENODEV; + return call_addr(WRITE,minor,buf,count,&filp->f_pos,filp->f_flags); +} + +------------------------------------------------------------------------- +Of course to have the ioctl to work in the major 1 we need to +change the ioctl.c too :-) + +---------------------------------------------------------------------- + +/* + * linux/fs/ioctl.c + * + * (C) 1991 Linus Torvalds + */ + +#include +#include +#include + +#include + +extern int tty_ioctl(int dev, int cmd, int arg); +extern int pipe_ioctl(struct inode *pino, int cmd, int arg); +extern int vga_ioctl(int dev, int cmd, int arg); + +typedef int (*ioctl_ptr)(int dev,int cmd,int arg); + +#define NRDEVS ((sizeof (ioctl_table))/(sizeof (ioctl_ptr))) + +static ioctl_ptr ioctl_table[]={ + NULL, /* nodev */ + vga_ioctl, /* /dev/mem (VGA temporarly ) */ + NULL, /* /dev/fd */ + NULL, /* /dev/hd */ + tty_ioctl, /* /dev/ttyx */ + tty_ioctl, /* /dev/tty */ + NULL, /* /dev/lp */ + NULL}; /* named pipes */ + + +int sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg) +{ + struct file * filp; + int dev,mode; + + if (fd >= NR_OPEN || !(filp = current->filp[fd])) + return -EBADF; + if (filp->f_inode->i_pipe) + return (filp->f_mode&1)?pipe_ioctl(filp->f_inode,cmd,arg):-EBADF; + mode=filp->f_inode->i_mode; + if (!S_ISCHR(mode) && !S_ISBLK(mode)) + return -EINVAL; + dev = filp->f_inode->i_rdev; + if (MAJOR(dev) >= NRDEVS) + return -ENODEV; + if (!ioctl_table[MAJOR(dev)]) + return -ENOTTY; + return ioctl_table[MAJOR(dev)](dev,cmd,arg); +} + +------------------------------------------------------------------------- +It is not finish... we need the include files now. +------------------------------------------------------------------------- + + +/* Data structures for IOCTL on /dev/screen */ +/* This goes in /usr/src/linux/include/linux/screen.h */ + +#ifndef _SCREEN_H +#define _SCREEN_H + +/* + * physical screen attributes; information returned by the + * SCRGETP ioctl call + */ +struct scr_param { + unsigned long scr_base; /* physical address of screen */ + unsigned int scr_fbsize; /* size of framebuffer */ + /* the following fields only have meaning in graphic modes. */ + unsigned short scr_width; /* width of screen (pixels) */ + unsigned short scr_height; /* height of screen (pixels) */ + unsigned short scr_depth; /* no. of bitplanes on screen */ + short scr_interlace; /* 1 if interlaced, 0 if not */ + /* the following fields on;y have meaning if interlaced */ + unsigned short scr_numpages; /* number of interlaced pages */ + unsigned short scr_pagesize; /* address distance between the + * first pixel in the first line + * and the first pixel in the + * second line + */ +}; + +/* ioctl(2) - commands that you can use with this stuff */ + +#define SCRGETP 1 /* return scr_parameters */ +#define SCRSETMODE 2 /* switch video mode (text/graphic) */ + +/* Possible vga configurations that you can have */ + +#define VGA_TEXT 3 /* text mode */ +#define VGA_640x480 4 /* graphics mode */ +#define VGA_600x800 5 /* graphics mode */ +#define VGA_1024x768 6 /* graphics mode */ + + +#endif /* _SCREEN_H */ + +------------------------------------------------------------------------- + +/* + * include/linux/videodef.h + * + * The values for EGA/VGA adapters (depending on which adapter you + * have, and which modes you want to use) are #included below by the file + * 'vga.h'. + */ + +/* + * struct scr_defs contains: + * 1. (in struct scr_param) the physical screen parameters, as defined + * in . + * This information, like number of pixels at the display ... are + * made available to user programs by the kernel (via ioctl()-call). + * + * 2. (in regs[]) the register values which should be written into the + * hardware registers when switching to this video mode. + * This information is only needed by the kernel itself. + */ + + +/* + * Definitions for EGA/VGA adapters. + */ +#include "vga.h" + +/* If you know where the address of your rom character map is + * you can save 8k in the kernel :-) + * #define ROM_CHAR_SET 0xC4F64L + */ + +------------------------------------------------------------------------ +The next one is the vga.h file generated by my vgaregs.exe using +vgaregs.exe 3 12 >vga.h from DOS. +You should generate you own and use that ! +This is included just to show how things are +--------------------------------------------------------------------------- + +#define HERC_TEXT_MODE \ + 0x20,0x61,0x50,0x52,0x0f,0x19,0x06,0x19,0x19,0x02,0x0d,0x00,0x0d + +#define HERC_TEXT_PARMS \ + 0xB0000L, 4000, 0, 0, 1, 0, 1, 0 + +#define HERC_GRAF_MODE \ + 0x02,0x35,0x2d,0x2e,0x07,0x5b,0x02,0x57,0x57,0x02,0x03,0x00,0x00 + +#define HERC_GRAF_PARMS \ + 0xB0000L, 32768, 720, 348, 1, 1, 4, 0x2000 + +#define REGBASE = 0x3D4 + +#define MODE_3 \ + 0x5F,0x4F,0x50,0x82,0x55,0x81,0xBF,0x1F,0x00,0x4F,0x0D,0x0E, \ + 0x00,0x00,0x00,0x00,0x9C,0x8E,0x8F,0x28,0x1F,0x96,0xB9,0xA3, \ + 0x00,0x01,0x02,0x03,0x04,0x05,0x14,0x07,0x38,0x39,0x3A,0x3B, \ + 0x3C,0x3D,0x3E,0x3F,0x0C,0x00,0x0F,0x08,0x00, \ + 0x00,0x00,0x00,0x00,0x00,0x10,0x0E,0x00,0xFF, \ + 0x03,0x00,0x03,0x00,0x02, \ + 0x67 + +/* PP( ) is a hack for cpp */ + +#define PARMS_3 \ + PP( 0xB8000L, 4000L, 0, 0, 4, 0, 1, 0 ) +#define VGA_TEXT_MODE MODE_3 +#define VGA_TEXT_PARMS PARMS_3 + +#define MODE_12 \ + 0x5F,0x4F,0x50,0x82,0x54,0x80,0x0B,0x3E,0x00,0x40,0x00,0x00, \ + 0x00,0x00,0x00,0x00,0xEA,0x8C,0xDF,0x28,0x00,0xE7,0x04,0xE3, \ + 0x00,0x01,0x02,0x03,0x04,0x05,0x14,0x07,0x38,0x39,0x3A,0x3B, \ + 0x3C,0x3D,0x3E,0x3F,0x01,0x00,0x0F,0x00,0x00, \ + 0x00,0x00,0x00,0x00,0x00,0x00,0x05,0x0F,0xFF, \ + 0x03,0x01,0x0F,0x00,0x06, \ + 0xE3 + +/* PP( ) is a hack for cpp */ + +#define PARMS_12 \ + PP( 0xA0000L, 38400, 640, 480, 4, 0, 1, 0 ) +#define VGA_GRAF_MODE MODE_12 +#define VGA_GRAF_PARMS PARMS_12 + +-------------------------------------------------------------------- +Ok. Before putting the actual vgaregs.exe in uuencode format.. few points. +1) I have a MONO monitor. and a unknown chipsed VGA +2) To use the thing my system MUST start in the default 80x25 and COLOR mode + If I start in a different screen mode then I have trouble! +3) What this gives you is a working example of switching. + NO graphics primitives areimplemented :-) + If you want to play just write something to + /dev/vga and see what happens. +4) When you are in graphics mode there is NO WAY to see messages from + the kernel or printf... + Here it is my SIMPLE program to test the thing. + +------------------------------------------------------------------------ + +#include +#include +#include +#include +#include + + +main () + { + int fd; + int i; + char val='a' ; + + if ( (fd=open("/dev/vga", O_RDWR) ) < 0 ) + { + printf ("cant open vga \n"); + exit (1); + } + + ioctl ( fd, SCRSETMODE, VGA_640x480 ); + + for (i=0; i<65000; i++ ) + if ( write (fd, &val, 1) < 1 ) + { + ioctl ( fd, SCRSETMODE, VGA_TEXT ); + printf ("i is %d ",i); + break; + } + + sleep (2); + ioctl ( fd, SCRSETMODE, VGA_TEXT ); + + lseek (fd, 0, SEEK_SET ); + + for (i=0; i<4000; i++ ) + write (fd, &val, 1); + + sleep (2); + ioctl ( fd, SCRSETMODE, VGA_640x480 ); + + sleep (2); + ioctl ( fd, SCRSETMODE, VGA_TEXT ); + lseek (fd, 0, SEEK_SET ); + + val = 0; + for (i=0; i<4000; i++ ) + if ( write (fd, &val, 1) < 1 ) + { + ioctl ( fd, SCRSETMODE, VGA_TEXT ); + printf ("i text is %d ",i); + break; + } + + close (fd); + } + +----------------------------------------------------------------- +The next program is the DOS program to catch the vag registes +------------------------------------------------------------------ + +begin 644 vgaregs.exe.Z +M'YV03;2$`Z`!``$`(`"8`_#O'YT!`!#X"<;N(``/`#(&`$"D@!X!]RP&*I`1 +MFT&^E$Z'$``!T8/208'M+C@F$EZQ"$G4MNE+<'@/SP6U!' +M`:XF>)/L%>!/:V9^&.;46/<)DCVY`N@4`&2@6H,`K_T!H3.-MFT!ZYA-'IO` +M`+4&ZX)!&DZNQ,%1VI#/@H1K"MX`H[-N#?6U@`&N;JVQ"\MOK"Y@`]SI"C:` +M7=TL>+4EL$K@-&?/8?`JFW^U-+_3%`=`(D:8!0T[N"1T7GJXG($7 +M*?QAI157=MA#WEAEZ>),>KH\TUY<_M35!EZ`\-?77]_1H8-]G>%2!UYI5.C? +M:0G(,0PN>^!E187:`;`A.;H0DYX.Q-1!!BX0K5/&S8252X0&&` +M5$?LBDL(`=1EK%0Y*/N!`,X>B\X*RD9";;'6=J#L1E+%,X!5`@P#R5%)L<-! +M4\<8`4]&[;*3T2!^$!!`'0.@$PJKPE"+C@JQXL*-OR`$',(`4ED0,`\(H\-` +MP&$T+$#`>S2,SP'DXH*>5.Y@?!4NVS1,CL<"[$*H(\/L,@8`)BQRP"A?U:4` +M`5(MXW%??JBSB!T&K!,%+J`\D(D4=4%",SJS>&P`+I@O`(QE#XQR'($&EK7(->R(_J`[Z'S!#^K?JW$T +M.[_S%0J<*T@3"P'1@!.--/XD4P<^1.,RQ]'1%/^[#U<"P#8!_X1R7"8%;#2( +M-``0'`$=.]"& +M'!1P!P+L`!EVZ(LV%H&,*?PL$$>K@_;$UP`@0&%]#XC%`*8!C@*0J2Z'.-H6 +MM)>.5_@#$IQ[QM&64#SPC>T=1_M!#?]A!':DXQC^,"`\%'$(/!0`$P@BA]CJ +M,H,"2"4$VA/;/^Q`#EQ0P8GHD$`4W94.3;PP$3P+A`^^0HT!U.$`[9)'DPJ0 +MQL)$+G*5PXLT0&`5`XBN5[\*%B1H`8-FA(`'`IB#`)H!@E_800!=0J0]'7",0Q+C,/N8``0M\`!WW",`,@"&5".+B'TSPXR#(X0\; +M),($@BB`*TW@AP)D:7DD1((-1L&'`@S@'HFP`4H8,8P5>.,>VZ"%$OQH`T9X +M8!X%L,`!^/$+020@%^!XP`J>,,RC\L`%`^^G$4 +M]2@`+@!0`S\FP@/A*``C##".`CC@`Q,M@2X`ZD=/+L(!G$#`.%S@"`-`LV4V +M8`$`BF$`3R"`$=J8P39L\`\/:`(!9B"#@O(Q3_^,$IYN*(.&5A' +M.0S@@0-\8!'W^`4_"L`*3$2"%?[(6@"0H`IQW,.3NS@(($ZQUU],E`A^7*`] +MA`$(V0#B$7L%PA+R<`Y?F`(!O_@L.D0!`,^"5K2*`,`PT.4+9"3@%ZY%1Q]* +M^]E?H`(!Z*!#H0;`VMO:%K=F**UO;XL.-@``';D``-;02J^#U(&-1@`?`'+Q +M``#L@B3V.,1>`T`'`M#"!WX<@CCD@8["+"*ZM$AE"$Z:TG$<8!E//5`, +M"V0TI'[\`"!\X($6-<`#H/B``>H+`@/0H@3Y'<8.[C$'!3SA"8MHP#CL\8]H +MK$,>"F:P`P:!PT448`%%B(T\_M&!=;AC&`!`%RZV(I4]"&`0/B!!B\!G`1DG +M5"II0"2P=H22=&S!'UE8!#=6@(T%[L`#)C"`'/HRCG^$8Y3I*((_K#`#>^0" +M*C(@!S]8(0-PB&,?@*!'%>C0`'2X@E7@0@<+!("+C7AA&(\P``H,H`N4X,`" +M$:5#"J1:`!.T5*8;Q8`!1IF)Y`)"JVY]ZSZ.<(1$^,`"!E#K/]QZCV@L(AJ_ +MV(@O,N6(9_*5!R"@PSYXD``ZW(,'#:##&Q20M34B(`.).`!%QXBA'608P;)"$*LAZT/7W=W`!:>QB*"$8UT3"`:J+B7 +M,M81`%CC>@6[/H&S=2%L8J^#'!C0'L0YJN_,$0AE`,&T":%:I@=1WT +ML>E^=AJ:ZQC`*%41ZU"/NM2G;@#;_@``C0]@'7F`1,0G[NU0;Z/6U\"U&';M +M!6>+>]@#4(6QT[UL.K";#@:`!1>\N8YH*+W:WIQ#TD4@]&)X.]4NV+4*G'V+ +M<@?]W$1?M[.3OG2A9^/IZ8BZ)6!!]74T8^2>/$9A&&*".:.K"A\O`+*GO8AT +M+"(?2>B*3!=@#SI`P!'&X*H/4H)TMQ;AK?HHPB6`0((@]B,:Y1A`?3]PA5\D +MX+B%`("OGK&(@^(C$2Y@9UT=X8TJ)V$<$P@$#W8P!-DDP@\`*$(1,*YQ?8BC +M'8EP@C@_T(4\KA8I5KA"71=A!0+X`A8(:,4.A&%X(%B"#@RXQ"@E[5:\KF,= +MEOB"%_+8KQ0CY0I3)``ZEO&/Y5)`$HO0Q_8;0NEH)`&^`*`%$/SH*V"5?Q'0 +M,``&$$MR4`,Y8`"]-`M@++,`#!@#(,ITQ^ +MA`5R``$D``](P$L%4`F+X`*Q%``6$$O#X!?I$`G[(`<3,$K&-P?X(!48``!8 +M<(,'@`X.`"D-D0G&EV7HL!'#(`KX4``*0`YU,`+[%5$#(`<-X&MS4(4@(`<% +M``MF0J$>2B`!UB`0& +ML#<&<(GWDPJ'SI(@!6L#-]80PM +M<(<1:!;(T#P:V#P%``ZW*!?VT(>#@'3?:`"[<0"G]`_I@`@`P(<&$!L&``A, +M8``@L`[M`(\&$``&Y`^`<`+[,(X,4`$`CK0(TCM`^+,`S1,`X#@`T+ +MF5W<>"\)D(L!0"[K8$M$0`")T!=>X`__<`>&TUV*0`0'@`E2P005,(Q$(`#+ +M50`]T!!P-0A\@!*R`0OS.`"0``L0@`!]>`PKF1'IX`?_`$-,@$@<\`\$H`@' +M,!;C%XE(H12R^(P\,Y(EB2#ZD"73:`#52$'82&TEQ(W$.([A:`#CN!MV$H\@ +M<([I``$!P([W\@[V*`"`0`8&\`ZBDP@K61:WQP_^6`>^,I`%J94'F9`+V9`/ +M>0@160=&T$BTB'2-9"QUH%5VH`_H<`090"Y84PT`!XJ9$8]T``6+P`,KP`=]D9%`L)$&9!:PB01XR9+_X`<3@'[=-464.0\4 +M,(Q:L0X:``D&I`_9M5>A]@"X@!)0(#I0``53@`Y\,`&+LPA%X$D)5; +M>8W@D(U?V8W^,%'^(@PIV8G"DPA'0`#+A1E/8``(D(^O&9O^:9["`P@OFHRZ +MH:(0",>BRA:0<& +M9`"*<`0E*15D<`&8F35D<%X&P*$C%* +M8`"+,`]WJ9$KN@XJ8*.?^0<$0)IT`*F^FIIU@`&7FJGHD`"<>A7+E0"I2B;D +M4JA,VA30N`+_,)(&0`(#`$B*N9N]"9C`::;$>9@120[.+H`S1$`YK.P!J&PX#@`R#D`XP<&E>B[,Z>S??D`@60+4+(`U(QYE(:YJ< +MZ;0WVP-&8!AFT`/"1P=9T`-H8!@.T`/&10='T`-P8!A24)MM8JD)8#X^(+6& +M,1L\``?/1;),4`P3,]0]8@'1N(K4H,0C' +M,(]HT+L)@!+K``S$2R;K@`O$:SGK``NSNP5UL`24`<$X!]&,%'- +M0AXFJ4X7BPX#8`&GZ``7NPX00+)=8'AHVW#9``@WL+HDZSWK4+](9SV[!0FB +M4Q:SFP8.*@EX8@!:,)O'M0*;8P`=:X$0^P]/(`!XP``N\P\'P'!*.1;KH`#J +M!+'H4`/Z0"[^^P\P4`=-P)E,RYD+[`$-_,`1/,$5C`T73`X9O,$)4%X?W(GX +M,+MX(!NSBP4:]`MX4"@G`$,HY:PV`+%7@`[4L&%\\0MO4"@2\`]%3,-)#`Q, +M3`"_0`;*]0]L`P7X>`PML#(]4`$`8`>IXC8#``R3X`+_<`HH4*\^@+3>DP"# +M.@I4>[0)`)_H0`,5>17IH`Z0LA'K$`\P-(!TK`!XL0#`<0[4H;STD#:A6[QT +M4!61#`$.>@B08CE2H0Y]_&(N(+*(Y`$BNPAW5<%7(`"CX`D)P+>@X*P*G``, +M[*PLC"4'0,$6O)0RO``P=,0U?`+Y`,(Y_`\Z4`4P#>#,HPYK2&D2K`D)OU\E4PIK3>4P+H4``$ +ML`X@L!RO>P`D$*/(``CY$``;``SW@`W+%0,P1M//Y1>(0`!&D$4LFC4>@`ZW +M,`!EL1OF^]-T\`U!_7ET4`P6>+&*$`"8L`[+,+M<7,L&L+#K4`1IH]8^`&-R +M3`<+&`D`-23=78L`X)H`A+/18E0"8M*L79S,M)G`BF +MR!=9_7EU4*]J/0#&.Q#:@T+!7:07\4-7G`P#WH`VYS>#CO8ZN*[9O +M?5X+S@^Q(`#_`SW2@P\#8`3Z,`$,_N$3S@\<5K?'D`FKJP\1P.`F7,-"P(OH +MH"W+E0C\30@7?@"`P#9Z\`^#X`^6G"I<\`^P0#/V+16B(`$]SEWC$KP]+@!L +MPU.X<`4`D`Y:%0H=:Y7MLA6Y.=.DO00PQK3>X]'69!@X`&.^&ZQLG@`04`<4 +M\,RP?%DK.%&"F-IKKW&/!_?7+RP+8E*P"X7$N8Z30<; +M)N8[G0X:@-P2T);H<`EZ8P2Z4!:-4`31:02V@`YG@(_P,.38;=/^T-TC,.3= +M;4O&@`@%<`123+7KX`"0P*"V8`<8P$/\D"6R?@3HH`.F?C_8P*HL"0QU,`Y# +M[@)UL`)Y$0#+10*Z;@KKO@(`B0X>$.]TL`&N7@<14.T,<)'5 +M7@'V+NRM`![WLZJ=6@?F\-\T?#_.H"*C[3V%;>YTT`'&0!)[HPN@:`,B&PI2 +M6P+NN5!*64>%?M.(7J&&6B\.<0%!FK=DA@Z:H%Q9LS2"C).BLZ07ZHSHX`+@ +ML0,1]%QLV@'LS<42U1#K$,53S,OW8P0J,JB%:ILH#,LJ+,L0K`"+<`,4K+(8 +M?`#S"0/T$*WF(HE"3PW_T!;V0`@ORYMG[Y$:Q)E\[=]1#['WXPZ[4JB"3=H2 +M)<@08-B?YP>U'-ZEZ0[\"PQICQ2X0`8%=0#P@+"U:`B>4+'``,M&`+*PH/D$ +M,`H4XB:ZL+%+P[#I,),^ZZ!8(`!NP@N?>]ZCPPI&BPI&:PM&JPI&2PM&*PM& +M:PI&*PI&ZPH8:P#&D``)`0A\$``CS`-&X";%;][K,`,DR^\-P)FR[R:\SRL`1&%T]``O,, +MZ2`-M"7.9/O'_5L'AK`2,BQFUOD(`#)#!Y.$7*2##\`J+$`'7C92@`W&`W%3`4!I4ZV`>P!!;$`21BP!(!QE`R*E`MV;6C($36`3^X`AT +ME='554I`':@'?F$%&`,HX`'N1SM@1;3J'N"O5,$'^@&,(8/>(\AX``IA#XZ` +M/*(#3\"A-0%-D`%L`08`!1D`(V)$55`1,0!'_(@9@"-Z`@R@##``-/"((3$# +M0(*4*`M0(D=4!)?)!XP^PV"??`!"K`,0P`(Q1(<(`NK`+2AIZR`30((QF``2 +MW87"`$VAN2B`UF;[&J$D\VBX+\Y9``L4!DV9G](*]L,?K,($<-14`(RQ?88A +M`E!%6'8`+I&5XA.X;BRZ#-R&%:V`5CR#+\8'O$$R9CS]P<.@CPEVBK-@N\($@@R[X +M("/L#72`BB((^K$#'LD.\`/9LA$`8X`,#`!"P`!!@!.1A'X"% +M=2`=!$;O00%"@>Q;``:`]S$7/Y`9GPLX+(9201;L(J.8+B!`4E1K%,`7;(10 +MT/F($2/P`A\,+L:@,!<5$:-:M(K$R'[$QV:HA\P3&"2+DS%!O,?]6+R<8IS# +M$@EB`9`X.8<+N$!_F@_FK@[0L3%0%@4D?#PO9L$*Z`,$(0_L!SU8`?8@$>D^ +M.L`!6F-IPG7$P`N,F,G!57Z`8:@`1F`'.`,_``'H$20P`BER10!_;'KRP2)*O3J;2T@4!8(^94"O6 +MBS.`=)K+$=!>L(`V"0`5``RL%HP)A!K$`GZ'T[#88,P$3),&P/5M!'5"^]2) +MZTL_ZB3S31&/9`$,@<=0`&R2#L"Q-U@',MI?=%86@#_90KGHUN#8FS24>M(" +M,`*2L16KE`'HBQG!.@[#[%AJ)L">7"B.0/YECP4,TH +M*'5C*:X>.9AN$RJ;7- +M0>)B1YC#E(%+*Z`#-1#F.&$=,`%)[!,CUB"D/G!N->!JNC4(N17P!3KP +M*DNR'Z*#:7`TH:1;:P#.S_@!@"06!L;F,@)_;DVBK(#=@CNDP@$8F^8"%Y@W +MJ;`/#.)5@#%],NU^TD70PJ'-BI>_`.5$>*^@%9@CP>*BO@"]3` +M`5`$=D,OWDC\I0!TP#^R!^#0YP&#JX$T@;?<"Y +M2$D!(#`[40'(`47@;G"*4^@]P,$_*`"TRW!@"849ZWQ<&:A+]B!^`DN:]PU^ +MDV`*3H1I7(V#R\*-HA&%`GI6,D@=&7U0`+301"E-*N`>;#X`4%F0`+U`9'1` +M`^R=:-!FA$!D60(J5`&@A#K@`$:<`3!Q""`/H(")8@'RP3IP)6[Q$EV:]F1# +M#X81^*%6((AB"2<01!C<1&FBZP`;,!]:Y00D@Q%0`+2@B6JAQ;)7^D$Z^`'D +M+.B)4`]`0N6``<@')W0=<`$;U$7'015(3P6`RKW#+KI%:<$/\"/70_>M`Q^` +M1RO+#2"C!6`?))]?)P_B#P49!R6`%C0`DJ4`3A=F,6JL`$G0@0S``S3`&;DL +M>P4X!,=9)P[603X4!N(G'2P#=#`(HEJ^X@%+\?N8`SRZ&S#`8_$C]T`8)`0) +MV0B2I!^-+-0`%BB`=<`"L@(L[*7_X)>&`!VQ7*0FJJ0#'T#2+-$`T$1S`>D4 +M2DOQ`,`"+&$%>H8EV*+K@!)DAG]02;?!.I@DL6B-ME%S!``20#Y(!TL`'>#1 +M4+,`F.@,C2SKH)#2`3>P1>O**+%MEX@?4*NKU"'-@%FHHU1`F+J5.J`$E%@5 +M%'=VP(5B*"&C"P"``.@!*""0#("1;M+#0 +M@X)5*,+`-CVI;G,'J0)AZNML8,TL%.*@5ZR#*M#7H$P.&`?R*0HL@F>P`I3! +M.,B)PD/_1);;(!>6BP'(`EN@!^F#8;`X`FEI\@"T%*U4*D#P`SSI`$AO#`". +M`@`.L`YHE5Q8`77*H/:*=-`&SH%('8Y;+1BD@S#@5KNI4@T!5M789"9PD%6] +MGC;@JEXUO3T#L4I6DT$6"`5)9@<0`ZFS`HA!57,RHV0=Z`-T$:06P#;H+CC* +M'Z1*$)I\=@$36O>`4OJ=<" +MDBR6"P'0)^N``I@`?^``%JQ@`*Z,X!KL@&,08#N-'JA@-V`=\()%<`<&S7#E +MFCO`&)`9$A``@``0P`3HP`LL-G_0!/P!.N``H\L2.`$G$!1AK'\-!MW%!(P" +MP^1;.UH%R,$JRP#"0`E$`'70`PX`4X6%;&`#R(+?N +MUAY[%E;`-5`"B:`*^`,LD`6TP#"8`E!@!D@##R`%J@>X,`"?I+HLCD&@#_[! +M!]`"6X`.L"1I@&+01?+Y'7Z`3-0!'%!-;$DWU5!(X(R@`^L@!TY`Z^P*TJ`` +M(`'!L&#HXDI"$`S@?LQ"+S`'8`#A(`"-)-E>C[\EFH;0.E"8VF`0#(,'$`VV +M001:![0`"426="`)-E(BH`)^R@8DVU%R`,2/\1D@$NP>Y("BA'VN;;8M`'5` +M'AA1[*D-!@`'D`,Y8!%,`ZRR8#1(#O``"<@$B%MRNPTLC,5=!PTW`0P`D09- +MB(QP]4#+M`$T7(UD`7J))$@AEX89K0[@*EP70;V8/Y/&%52:)!`)XD^P,#^K +M\@K,@BSWVRBK\!BA!:`/;+1]X#@80%8EE7K1!NT8G)M\E(("R`KVH!EHJ+AP +M:GZ6`N`!)@#I9`5\L`RR5%;0!\L@*^0#(K!UB0`CL`+T8&_8`P[ID" +MB*0)](4J0*NHU"+H`PJ@G*G(+B!07:XE*@")`.XF`KF;:6\1E7H$14`!+)DJ +M$QE>X3A0CUP!\-:!T*8`[*VJ5`H,P'WN#7K@Z3:?;3,&\3,))`+ME0AJP/T8 +M?^0B$8283Q2*DA@I8*6:@SRNW.`*#%QN7_@&(G4<5("P8*G`P3TX!H%!`*B" +M)`!U5L$$2`;>)/Y,@IL[0+S>P?RUN5;Y3)-)L&OL4SZHI`[@;^D%6-`"5`$R +M>7`1#J](`E&[7$!"/)@$]R`>G-QI0`!@``]8;0*``)P`5:`6%L`PJ`/B0-8] +M`59@"((C$?@'C8`(!(`9*P?D`1:PO#>7LCY1`Z(`%H`6]0*\:0%HJ'LP#L@/ +MF:#`%&0"FP$%$+<&*9>Q"$[9`)$G329( +MZ3D7['\L@DQH`E,`!$B!.N`&6@`52`-MH`R``":0!L2`'`@#PW7X#N=A0=R' +MX;`!-X"*-?$<&,9C0!RG@53\BZTP'9#&8^`-M($V$`9.,0A@`[RX#+`` +MQ5L&P@`96,C2^!R?@4QD<$Y>Q2``%==C:NP&A/!' +M%L+9^!R;XDV,A,-`$*['>T#'E#5]H#9T#)K2$?L,P@`Q,Z`>- +M!T+T=(;/\KDHTV?[C)_U,W_^`E`@"$@!'#R@\?`;%@(P($?#`":P'&F`CEZ. +M!]HY+\<%+:2W,)`^T?&Y#)!E(5R?[_,7.`)2(`@8`?\,H`6TKB'0)?I#XX$9 +M4`,8M`P0T05:)8/H&\"@:X`8\-!EFDQ#:#6=I2?T#!C1(QI)IV@FS:*?=)2> +MTC%Z1N?@*VVC\0".UM$\&@3,`!EP`VS`%P8!-\!`+\<90`,.-9$FTC0`2.,! +M`YVCY;22GL]2H`@<`2$0!*:`@.X!SMD0SX!*C,A*`![X`J8:15]J%?V?`S2J +MUL176@&\`!4``N(3"@`!6E@4`V,T$`;&P!KPSE1Y#,"!6*P"7@`B4P!)>DG7 +M:AF-@U]UC:[54.!6^V$V@`5X-$(H`<>X#I<`$0T"MK6V[LN!&B$$Z0.-$")U +MD2;2,`!7([)9#0):=1$H`9K8#;P!*]RKZ4`=0,AL0`FG8XY@P!Y3:\+ +M\[U.R/IZ#O!K8ZVPYW2W'@,!VTY+:2H=H`]VE4[8JEI9EP"4[;"A],J.V%-@ +M8NMIBXT0//5*R`/?H8P!K*)`M&-"+*$]7\`()`$F4`2^0!)P`D;@"0`%"@`` +M`H'5#@`;02=H``-P2(9`3``'EB,C6``!(``P0`-(``P@;<,L"V`!_H$$:``2 +MP'!D!&JP)P``W<[:*T$`X.V40+99`B&`"'G;!A?MP4VX:T+6'MJ%.W$K[I(0 +MM%%`<$[(*0``..XZ`+G/&Q,>`3DA(:0$%W``.+?G[MQS9R7@X=%-NE&`Z3;= +MI#MUJ^[1C00@@.M^W;`[=A."V4V[:W?L=MU6.W<'`JS-NWNW[_[=MUL0"._A +M3;:+M_$^WL@;=FONQP-`V;`]F;"8-DR$V/!W)I!@!A0PC``?7^> +M]9VC<\#[WMCSNBK+ZSI`A;$Q'.C5S?@9FV*`3(;=0!`FQ>A[*Z!O6"@'>#!U +M`\)".!>3X6=L4;%WCI8!_YM\OX$PL(N;,QQX`V`9@%OA\NV24S'ZW@C\&P;$ +=@/_]N-G`)D;AI)@8AX$YH([/@`,WQ60&D36$?P`9 +` +end + + + +Ok, then, It is all. +Have fun ! + +Damiano + +P.S. It should be easy to use the /dev/vga device to have +preview in gostscript, after all gostscript needs just B/W and +a framebuffer...... :-) + + +From linux-standards-request@banjo.concert.net Mon Mar 30 17:10:07 1992 +Return-Path: +Received: from dg-rtp.rtp.dg.com by banjo.concert.net with SMTP (PP) + id <15550-0@banjo.concert.net>; Mon, 30 Mar 1992 17:09:38 -0500 +Received: by dg-rtp.dg.com (5.4/dg-rtp-proto) id AA07511; + Mon, 30 Mar 1992 17:09:33 -0500 +Received: by ponds.UUCP (smail2.5) id AA27281; 30 Mar 92 13:34:31 EST (Mon) +To: banjo.concert.net!linux-standards-request@dg-rtp.dg.com, + linux-standards@banjo.concert.net +Subject: Re: Ok, we have been envoked. +Message-Id: <9203301334.AA27277@ponds.UUCP> +Date: 30 Mar 92 13:34:30 EST (Mon) +From: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers) + +I prefer names like (as least as far as floppy/hard disks are concerned): + + /dev/dsk/fd096 1.44 meg floppy disk + /dev/dsk/0s0 Entire first SCSI disk + /dev/dsk/0s1 Partition #1 of first SCSI disk + /dev/dsk/0s2 Partition #2 of first SCSI dsik + ... + /dev/dsk/0p0 First MFM disk (entire disk) + /dev/dsk/0p1 First partition of first MFM disk + /dev/dsk/0p2 + + with analagous /dev/rdsk/xxxx for the raw devices. + + Also, we might provide links from /dev/dsk/xxx to /dev/xxx for an + installed (autoconfiged?) disk. That was, all the possible names + don't clutter up the /dev directory... only the names a user would + want to see. + + This is also rather SysVish - don't get the idea I thought of this + on my own... :-) + + + - Dave R. - + + p.s. We may want to consider such a naming scheme for tapes as well. + + + +From linux-standards-request@banjo.concert.net Mon Mar 30 18:55:20 1992 +Return-Path: +Received: from twok.ods.com by banjo.concert.net with SMTP (PP) + id <15918-0@banjo.concert.net>; Mon, 30 Mar 1992 18:55:02 -0500 +Received: by istwok.ods.com id AA24727 (5.65c/IDA-1.3.5); + Mon, 30 Mar 1992 17:57:52 -0600 +From: David Engel +Message-Id: <199203302357.AA24727@istwok.ods.com> +Subject: Re: Ok, we have been envoked. +To: linux-standards@banjo.concert.net +Date: Mon, 30 Mar 92 17:57:51 CST +In-Reply-To: <199203301413.AA16702@istwok.ods.com>; from "Alan B Clegg" at Mar 30, 92 9:07 am +X-Mailer: ELM [version 2.3 PL11] + +> Ok, since the file system standard went over so well, I propose this +> (open for discussion): + +Ok, I'll throw my two cents worth in. + +The easy ones first: :) + +wd0 first winchester disk, entire disk +wd0[abcd] first winchester disk, primary partitions +wd0[e-z] first winchester disk, logical partitions +wd[1-]* other winchester disks, etc. + +fd0 first floppy drive, default format assigned by user +fd0[a-g] first floppy drive, formats defined in floppy.c +fd[1-N]* other floppy drives, etc. + +lp0 first parallel printer port +lp[1-N] other parallel printer ports + +Now, the hard ones. I've yet to see or come up with anything that I +truely like, but the following are starting to grow on me. + +vt0 (or ttyv0) current virtual terminal +vt1 first virtual terminal +vt[2-N] other virtual terminal + +tty0 first serial port, assigned by the user +tty[1-N] other serial ports, assigned by the user + +-David + +-- +David Engel Optical Data Systems, Inc. +david@ods.com 1101 E. Arapaho Road +(214) 234-6400 Richardson, TX 75081 + +From linux-standards-request@banjo.concert.net Mon Mar 30 20:44:52 1992 +Return-Path: +Received: from uu.psi.com by banjo.concert.net with SMTP (PP) + id <16186-0@banjo.concert.net>; Mon, 30 Mar 1992 20:40:02 -0500 +Received: from access.digex.com by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) + id AA29035; Mon, 30 Mar 92 20:11:18 -0500 +Received: by access.digex.com + id AA29608 (5.65b/IDA-1.4.3/Access-1.1 - Digital Express); + Mon, 30 Mar 92 18:57:38 -0500 +Date: Mon, 30 Mar 92 18:57:38 -0500 +From: "Joseph R. Massi" +Message-Id: <9203302357.AA29608@access.digex.com> +To: jwinstea@jarthur.Claremont.EDU +Cc: abc@banjo.concert.net, linux-standards@banjo.concert.net +In-Reply-To: "Jim Winstead Jr."'s message of Mon, 30 Mar 92 9:36:47 PST <9203302000.AA22543@uu.psi.com> +Subject: Ok, we have been envoked. + +I agree with Jim, keep the generic AT drives on hd and zero base the +serial ports and lp ports. + +joe. +------------------------------------------------------------------------------- +Joe Massi e-mail: jrmassi@access.digex.com +Columbia, MD packet radio: kb2jg@w3iwi.md.usa.noam... + USnail/Phone/Fax: ask + disclaimer: Who me? Claim something? + +From linux-standards-request@banjo.concert.net Mon Mar 30 21:03:30 1992 +Return-Path: +Received: from nic.stolaf.edu by banjo.concert.net with SMTP (PP) + id <16302-0@banjo.concert.net>; Mon, 30 Mar 1992 21:03:13 -0500 +Received: from amcl5.math.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA09875; + Mon, 30 Mar 92 20:03:04 CST +Date: Mon, 30 Mar 92 20:03:04 CST +From: johnsonm@stolaf.edu (Michael K. Johnson) +Message-Id: <9203310203.AA09875@stolaf.edu> +Received: by amcl5.math.stolaf.edu (4.1/SMI-4.1) id AA07102; + Mon, 30 Mar 92 20:03:03 CST +To: linux-standards@banjo.concert.net +In-Reply-To: David Engel's message of Mon, 30 Mar 92 17:57:51 CST <199203302357.AA24727@istwok.ods.com> +Subject: Ok, we have been envoked. + + From: David Engel + + wd0 first winchester disk, entire disk + wd0[abcd] first winchester disk, primary partitions + wd0[e-z] first winchester disk, logical partitions + wd[1-]* other winchester disks, etc. + +wd or hd, I don't care -- might just stay with hd -- it seems to work +well.... + + fd0 first floppy drive, default format assigned by user + fd0[a-g] first floppy drive, formats defined in floppy.c + fd[1-N]* other floppy drives, etc. + +With the mess of fd's that we have on PC's, there is no perfect +solution here -- but I like the orthagonality... It would be nice to +_also_ specify names that describe the drive... + + lp0 first parallel printer port + lp[1-N] other parallel printer ports + +Of course. + + Now, the hard ones. I've yet to see or come up with anything that I + truely like, but the following are starting to grow on me. + + vt0 (or ttyv0) current virtual terminal + vt1 first virtual terminal + vt[2-N] other virtual terminal + +I prefer vc0, vc2, ... vcn, since the name we have been using is +virtual console. Does this make sense? + + tty0 first serial port, assigned by the user + tty[1-N] other serial ports, assigned by the user + +yeah... + + -David + +michaelkjohnson +johnsonm@stolaf.edu + + + +From linux-standards-request@banjo.concert.net Tue Mar 31 11:12:58 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <18584-0@banjo.concert.net>; Tue, 31 Mar 1992 10:57:27 -0500 +Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP + id <23090-0@sun2.nsfnet-relay.ac.uk>; Mon, 30 Mar 1992 21:08:42 +0100 +Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa15165; + 30 Mar 92 21:03 BST +Date: Mon, 30 Mar 92 20:56:32 +0100 +From: Damiano Bolla +To: abc@banjo.concert.net, linux-standards@banjo.concert.net +Subject: Re: Ok, we have been envoked. + +Yup I like it. +Just one thing.... :-) +If you PREFIX the thing with something meaninful +Ex: The harddisk being saomething like +hd..... +the tape being something +mt.... +We leave the tty or do ve have something like +ser..... +The same for the video +fb.... ( Frame buffer ) +And more for the floppy +flp...... + +Then you can add stuff and be shure that you don't conflict. +Ex the hd can be something +hdwd1 +hdwd2 ( or a, b , c .. ) +hdsc1 + +and so on the same is valid for the rest +Something like the first three chars are to identify the device +the next three chars identify the brand name +and the remaining 2 chars identify what device it is of the possible. +Of cource if you have other flags you can append at the end :-) +( Eg. the tape can be : +mtcolr0 as for Tape, Colorado, 0 density with rewind +or +mtcolnr0 as for tape Colorado 0 density no rewind + + +Damiano + + +From linux-standards-request@banjo.concert.net Tue Mar 31 11:19:13 1992 +Return-Path: +Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP) + id <18738-0@banjo.concert.net>; Tue, 31 Mar 1992 11:18:31 -0500 +Received: by sumax.seattleu.edu id AA18493 (5.65a/IDA-1.4.2 + for linux-standards@banjo.concert.net); Tue, 31 Mar 92 08:20:27 -0800 +Date: Tue, 31 Mar 92 08:20:27 -0800 +From: Chuck Boyer +Message-Id: <9203311620.AA18493@sumax.seattleu.edu> +To: abc@banjo.concert.net, db1@ukc.ac.uk, linux-standards@banjo.concert.net +Subject: Re: Ok, we have been envoked. + +/hdwd0 +/hdwd1 +/hdwd2..... + +/hdscssi0 +/hdscssi1 +/hdscssi2... + +/at0 +/at1 +/xt0 +/xt1 + +All else looks okay.... as suggested. +chuck + +From linux-standards-request@banjo.concert.net Tue Mar 31 11:28:24 1992 +Return-Path: +Received: from ATHENA.MIT.EDU by banjo.concert.net with SMTP (PP) + id <18807-0@banjo.concert.net>; Tue, 31 Mar 1992 11:27:46 -0500 +Received: from SOS.MIT.EDU by Athena.MIT.EDU with SMTP id AA23783; + Tue, 31 Mar 92 11:27:33 EST +Received: by SOS (5.57/4.7) id AA24957; Tue, 31 Mar 92 11:27:28 -0500 +Date: Tue, 31 Mar 92 11:27:28 -0500 +From: Theodore Ts'o +Message-Id: <9203311627.AA24957@SOS> +To: Chuck Boyer +Cc: abc@banjo.concert.net, db1@ukc.ac.uk, linux-standards@banjo.concert.net +In-Reply-To: Chuck Boyer's message of Tue, 31 Mar 92 08:20:27 -0800, <9203311620.AA18493@sumax.seattleu.edu> +Subject: Re: Ok, we have been envoked. +Reply-To: tytso@Athena.MIT.EDU +Address: 1 Amherst St., Cambridge, MA 02139 +Phone: (617) 253-8091 + + Date: Tue, 31 Mar 92 08:20:27 -0800 + From: Chuck Boyer + + /hdwd0 + /hdwd1 + /hdwd2..... + + /hdscssi0 + /hdscssi1 + /hdscssi2... + +Blech! Those names are ugly! I would much rather prefer /dev/wd, +/dev/sd, etc..... People will learn fairly quickly what they are; and +in any case the "d" in "wd" and "sd" should be enough of a tipoff that +we're talking about a disk unit instead of a tape unit. + +I would also make a plug for NOT using /dev/disk/XXXX. I know "modern" +AT&T Unices are trying to do this, but my experience is that it's (1) +painful to type and (2) confuses a lot of programs who expect /dev to be +a flat directory. + +As for zero based versus one based for the serial ports, I would make +the argument that (for better or for worse) due to long association with +MS-DOS the hardware ports for the "first" serial port and the "second" +serial port are COM1 and COM2. While renumbering them to be zero based +may be the Unix Way, I think that it will cause way to much confusion. +I would much rather see /dev/ttys1, /dev/ttys2, /dev/ttys3, and +/dev/ttys4 for COM1, COM2, COM3, and COM4, respectively. + + - Ted + +From linux-standards-request@banjo.concert.net Tue Mar 31 11:47:54 1992 +Return-Path: +Received: from kinglear.cs.colorado.edu by banjo.concert.net with SMTP (PP) + id <18962-0@banjo.concert.net>; Tue, 31 Mar 1992 11:47:30 -0500 +Received: from localhost by kinglear.cs.Colorado.EDU with SMTP + id AA19049 (5.65c/IDA-1.4.4 for linux-standards@banjo.concert.net); + Tue, 31 Mar 1992 09:47:13 -0700 +Message-Id: <199203311647.AA19049@kinglear.cs.Colorado.EDU> +To: Chuck Boyer , linux-standards@banjo.concert.net +Subject: Re: Ok, we have been envoked. +In-Reply-To: Your message of Tue, 31 Mar 92 08:20:27 -0800. <9203311620.AA18493@sumax.seattleu.edu> +Date: Tue, 31 Mar 92 09:47:11 MST +From: drew@kinglear.cs.Colorado.EDU + + +-------- + + /hdwd0 + /hdwd1 + /hdwd2..... + + /hdscssi0 + /hdscssi1 + /hdscssi2... + +This is just plain nasty. Aside from the fact that SCSI is spelled with one +S and not two, normal systems traditionally name their SCSI disks +/dev/sd[drive][partition], where drive is a number, +and partition a letter. Normal disks are named in the same way, +with some other prefix. wd would not be objectionable, hd is +fairly mnemonic and works well for me. + + /at0 + /at1 + /xt0 + /xt1 + +Again, counter intuitive. What the hell is a /dev/at? Or a /dev/xt? +What's wrong with /dev/fd[drivenumber][somesort of density code] +-------- + +From linux-standards-request@banjo.concert.net Tue Mar 31 11:54:34 1992 +Return-Path: +Received: from qucis.queensu.ca by banjo.concert.net with SMTP (PP) + id <19053-0@banjo.concert.net>; Tue, 31 Mar 1992 11:53:57 -0500 +Received: from qusuna.qucis.queensu.ca by qucis.queensu.ca (4.1/SMI-4.1-qs1.2) + id AA14684; Tue, 31 Mar 92 11:53:34 EST +From: lalonde@qucis.queensu.ca (Paul Lalonde) +Received: by qusuna.qucis.queensu.ca (4.1/SMI-4.0-qc1.1) id AA26935; + Tue, 31 Mar 92 11:53:30 EST +Date: Tue, 31 Mar 92 11:53:30 EST +Message-Id: <9203311653.AA26935@qusuna.qucis.queensu.ca> +To: linux-standards@banjo.concert.net +Subject: Com port naming + +Ted writes: +> From: Chuck Boyer + +> /hdwd0 +> /hdwd1 +> /hdwd2..... + +> /hdscssi0 +> /hdscssi1 +> /hdscssi2... + +>Blech! Those names are ugly! I would much rather prefer /dev/wd, +>/dev/sd, etc..... People will learn fairly quickly what they are; and +>in any case the "d" in "wd" and "sd" should be enough of a tipoff that +>we're talking about a disk unit instead of a tape unit. + + I agree. Very ugly. I prefer wd and wd, with links to hd[0-?]. + +>As for zero based versus one based for the serial ports, I would make +>the argument that (for better or for worse) due to long association with +>MS-DOS the hardware ports for the "first" serial port and the "second" +>serial port are COM1 and COM2. While renumbering them to be zero based +>may be the Unix Way, I think that it will cause way to much confusion. +>I would much rather see /dev/ttys1, /dev/ttys2, /dev/ttys3, and +>/dev/ttys4 for COM1, COM2, COM3, and COM4, respectively. + +I much prefer zero based ports. Dos is brain-dead and I see no reason +to keep it that way. Even the boards are labelled 0 and 1 (at least on +my box). So use /dev/ttys[0-3], and make links to /dev/com[1-4] if +you need them. Or even put the existence of the links in the standard +if you feel very stronly about them. But /dev/ttys[1-4] is just too +much of a nasty hybrid. + + Paul + + Paul A. Lalonde Internet: lalonde@qucis.queensu.ca + Home Phone: (613)549-0605 Work Phone: (613)545-6754 + + "The only true law is that which leads to freedom" + - Richard Bach, _Jonathan Livingston Seagull_ + +From linux-standards-request@banjo.concert.net Tue Mar 31 12:01:52 1992 +Return-Path: +Received: from kinglear.cs.colorado.edu by banjo.concert.net with SMTP (PP) + id <19182-0@banjo.concert.net>; Tue, 31 Mar 1992 12:01:27 -0500 +Received: from localhost by kinglear.cs.Colorado.EDU with SMTP + id AA19074 (5.65c/IDA-1.4.4 for linux-standards@banjo.concert.net); + Tue, 31 Mar 1992 09:58:49 -0700 +Message-Id: <199203311658.AA19074@kinglear.cs.Colorado.EDU> +To: Damiano Bolla , linux-standards@banjo.concert.net +Subject: Re: Ok, we have been envoked. +In-Reply-To: Your message of Mon, 30 Mar 92 20:56:32 +0100. <199203311629.AA12987@torreys.cs.colorado.edu> +Date: Tue, 31 Mar 92 09:58:48 MST +From: drew@kinglear.cs.Colorado.EDU + + +-------- + + Yup I like it. + Just one thing.... :-) + If you PREFIX the thing with something meaninful + Ex: The harddisk being saomething like + hd..... + the tape being something + mt.... + We leave the tty or do ve have something like + ser..... + The same for the video + fb.... ( Frame buffer ) + And more for the floppy + flp...... + + Then you can add stuff and be shure that you don't conflict. + Ex the hd can be something + hdwd1 + hdwd2 ( or a, b , c .. ) + hdsc1 + +Long and blecherous. I have Unix systems that have HPIB disks, SCSI disks, +exabytes, 1/4" tape, and serial printers all on them at the same time. There +isn't a naming conflict. Let's stick to *normal* device +namings, short, concise and to the point. + + and so on the same is valid for the rest + Something like the first three chars are to identify the device + the next three chars identify the brand name + +The drivers should take care of this for you, like the SCSI drivers +do, so that no matter what SCSI adapter you have (currently, +Ultrastor and Seagate adapters are supported, RSN Adaptec, and soon +DTC and CSC adapters) do, you only have one /dev/sd* set of devices, +and one set of major/minor numbers to deal with. + +If I used a major and Unique device name for every host adapter that +would eventually be supported, there would be over a dozen +major numbers, /dev/hdsdadp0a, /dev/mtstsea0, etc. + +This makes it very convoluted. + + and the remaining 2 chars identify what device it is of the possible. + Of cource if you have other flags you can append at the end :-) + ( Eg. the tape can be : + mtcolr0 as for Tape, Colorado, 0 density with rewind + or + mtcolnr0 as for tape Colorado 0 density no rewind + + + +From linux-standards-request@banjo.concert.net Tue Mar 31 12:23:27 1992 +Return-Path: +Received: from sage.cc.purdue.edu by banjo.concert.net with SMTP (PP) + id <19356-0@banjo.concert.net>; Tue, 31 Mar 1992 12:22:59 -0500 +Received: by sage.cc.purdue.edu (5.61/Purdue_CC) id AA17565; + Tue, 31 Mar 92 12:22:47 -0500 +From: asg@sage.cc.purdue.edu (Bruce Varney) +Message-Id: <9203311722.AA17565@sage.cc.purdue.edu> +Subject: Re: Ok, we have been envoked. +To: drew@kinglear.cs.Colorado.EDU +Date: Tue, 31 Mar 92 12:22:46 EST +Cc: linux-standards@banjo.concert.net +In-Reply-To: <199203311647.AA19049@kinglear.cs.Colorado.EDU>; from "drew@kinglear.cs.Colorado.EDU" at Mar 31, 92 9:47 am +Needs: Your attention +Organization: Fraternal Order of Red-haired Milkmaids + + + +How about this: + +/dev/hdw[0-9] +/dev/hds[0-9] (for scsi disks) +etc. + +Or alternatively: +/dev/whd[0-9] +/dev/shd[0-9] +etc. + +Then, prepend an r for the raw disk devices: +/dev/rhdw[0-9] (for character disk devices) +etc. + +As for floppies, well, the major and minor numbers should be what determines +the density, and it should be +/dev/fd0, /dev/fd1, etc. +I would have no need for a /dev/fd1ld (or whatever would designate low density). +Simply, for most people, the type of their disk drives is relativiley fixed. +(i.e., it doesn't change often). mknod /dev/fd[0-9] to the appropriate major +and minor numbers, and off you go. + +As for ttys: + +/dev/console should refer to the ENTIRE console, not just one virtual +window. This is so that any error message that is printed to the console +will come up on your screen (for the user at the machine itself) no matter +which virtual console you are on. + +/dev/tty0 should also be the console, and then start VC's with /dev/tty1 +(this makes the tty number correspond with the VC number) + +Other (non console, non VC) ttys should be designated slightly differently +(these are things like the modem port). tty[a-z,A-Z] would be a good idea. +If you wish to ln /dev/com1 to /dev/ttya (or whatever) that is fine. + +then for ptys, the make /dev/tty[a-z,A-Z][a-z,A-Z] the slave devices, and +/dev/pty[a-z,A-Z][a-z,A-Z] the corresponding master devices. + +Of course, /dev/tty still applies to the current tty. + +And then /dev/rmt[0-9] for tape drives. + +Well? + + Bruce + +From linux-standards-request@banjo.concert.net Tue Mar 31 12:30:34 1992 +Return-Path: +Received: from ATHENA.MIT.EDU by banjo.concert.net with SMTP (PP) + id <19395-0@banjo.concert.net>; Tue, 31 Mar 1992 12:30:08 -0500 +Received: from SOS.MIT.EDU by Athena.MIT.EDU with SMTP id AA28198; + Tue, 31 Mar 92 12:29:56 EST +Received: by SOS (5.57/4.7) id AA24997; Tue, 31 Mar 92 12:29:54 -0500 +Date: Tue, 31 Mar 92 12:29:54 -0500 +From: Theodore Ts'o +Message-Id: <9203311729.AA24997@SOS> +To: lalonde@qucis.queensu.ca +Cc: linux-standards@banjo.concert.net +In-Reply-To: Paul Lalonde's message of Tue, 31 Mar 92 11:53:30 EST, <9203311653.AA26935@qusuna.qucis.queensu.ca> +Subject: Re: Com port naming +Reply-To: tytso@Athena.MIT.EDU +Address: 1 Amherst St., Cambridge, MA 02139 +Phone: (617) 253-8091 + +I don't know about you, but all of my documentation for my serial cards +(admittedly, they're rice paddy specials) use COM1 and COM2 when +describing the various jumper positions. I have yet to see a hardware +documentation for serial cards which use a zero-based notation --- if +they don't use the COM1-4 designation, they use the I/O port base +address. (Perhaps I am wrong; if someone can present me with evidence +that a majority of the hardware actually uses a zero-based system, +please do so. I would be very surprised.) + +I agree that DOS is bletcherous. But that's beside the point. The +question is which would be more confusing: a zero-based or one-based +numbering scheme for serial ports. I would argue that the one-based +numbering scheme goes beyond DOS --- that's the way things are screened +onto the PC boards (as jumper positions) of many serial cards, and that +few (if any) hardware documentation uses a zero-based system. + +Granted, the fact that most hardware refers to COM1-4 ports is due to a +long assotiation with DOS; the hardware people didn't want to create +boards which would be confusing to the vast installed base of MS-DOS +users --- up until recently, if you purchased a PC clone, there would be +a 99.97% chance you would be running DOS. I know a lot of people +believe that a zero-based system would be aesthetically cleaner, but we +lost that chance about eight years ago. If we use a zero-based system, +it will be us who will be confusing a lot of users by bucking a +long-standing convention. + + - Ted + + +From linux-standards-request@banjo.concert.net Tue Mar 31 14:47:57 1992 +Return-Path: +Received: from nic.stolaf.edu by banjo.concert.net with SMTP (PP) + id <19844-0@banjo.concert.net>; Tue, 31 Mar 1992 14:47:25 -0500 +Received: from amcl13.math.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA26750; + Tue, 31 Mar 92 13:47:15 CST +Date: Tue, 31 Mar 92 13:47:15 CST +From: johnsonm@stolaf.edu (Michael K. Johnson) +Message-Id: <9203311947.AA26750@stolaf.edu> +Received: by amcl13.math.stolaf.edu (4.1/SMI-4.1) id AA16988; + Tue, 31 Mar 92 13:47:14 CST +To: linux-standards@banjo.concert.net +In-Reply-To: Paul Lalonde's message of Tue, 31 Mar 92 11:53:30 EST <9203311653.AA26935@qusuna.qucis.queensu.ca> +Subject: Com port naming + + From: lalonde@qucis.queensu.ca (Paul Lalonde) + + I much prefer zero based ports. Dos is brain-dead and I see no reason + to keep it that way. Even the boards are labelled 0 and 1 (at least on + my box). So use /dev/ttys[0-3], and make links to /dev/com[1-4] if + you need them. Or even put the existence of the links in the standard + if you feel very stronly about them. But /dev/ttys[1-4] is just too + much of a nasty hybrid. + +I second the motion: ttys[0-4] (or whatever we call the serial ports) +and if people want to call them com[1-4], that's fine. I think that +saying that people will be confused by the zero-base is looking too +much in the short term -- if we have com[1-4] as links, people won't +get too confused now, and as people come to understand that most of +the devices (with the exception of devices where there is a concept of +"current device") are zero-based, then ttys/tts[0-3] will make more +sense. I vote for the long run, as I see it... + +just my $0.02. + +michaelkjohnson +johnsonm@stolaf.edu + +From linux-standards-request@banjo.concert.net Tue Mar 31 18:03:04 1992 +Return-Path: +Received: from golem.wcc.govt.nz by banjo.concert.net with SMTP (PP) + id <20676-0@banjo.concert.net>; Tue, 31 Mar 1992 18:02:36 -0500 +Received: from csc.wcc.govt.nz by golem.wcc.govt.nz id ; + Wed, 1 Apr 92 10:02:32 +1200 +Received: by csc.wcc.govt.nz (MX V3.0) id 2220; Wed, 01 Apr 1992 11:03:45 EST +Sender: hamilton +Date: Wed, 01 Apr 1992 11:03:38 EST +From: hamilton@csc.wcc.govt.nz +To: linux-standards@banjo.concert.net +Cc: hamilton@csc.wcc.govt.nz +Message-Id: <00958734.4AA898A0.2220@csc.wcc.govt.nz> +Subject: Ok, we have been envoked. + + +I had a bit of trouble getting this message out (this is a VMS box - need +I say more:), so I apologize if you receive more than one copy. + +>... +>/dev/console should refer to the ENTIRE console, not just one virtual +>window. This is so that any error message that is printed to the console +>will come up on your screen (for the user at the machine itself) no matter +>which virtual console you are on. +>... + +What if something goes bananas and constantly writes messages to +/dev/console. You might have trouble getting typing in edgeways in +order to correct the situation (unless you have a terminal attached to +comm[0-3]). I guess you could have some way of enabing messages to +one set of vc's only, so that one or more would remain idle. + +If we're going to go with zero based, lets be consistent. No +exceptions for the comm's ports. One simple README should be able +to explain a consistent system. + +I'm not sure I like the zero (0) device being special/different from +the other devices (1-n) in some cases, and not in others. Perhaps to +be consistent, the zero device should always be reserved for something +special. And if there isn't anything special, there shouldn't be one. +If this were the case comm1 would probably be the appropriate name for +comm's port 1. + +If there are going to many different types of controller perhaps I would +prefer a naming hierarchy. It would certainly make it easier to handle +variants (for example /svga/video-7/vram). Drives would be similar: + +/hd/wd/0 +/hd/wd/1 +/hd/wd/2 +/hd/scsi/0 +/hd/scsi/1 +/hd/scsi/2 + +From linux-standards-request@banjo.concert.net Tue Mar 31 19:49:38 1992 +Return-Path: +Received: from romeo.cs.colorado.edu by banjo.concert.net with SMTP (PP) + id <20846-0@banjo.concert.net>; Tue, 31 Mar 1992 19:49:16 -0500 +Received: from localhost by romeo.cs.Colorado.EDU with SMTP + id AA18238 (5.65c/IDA-1.4.4 for linux-standards@banjo.concert.net); + Tue, 31 Mar 1992 17:49:10 -0700 +Message-Id: <199204010049.AA18238@romeo.cs.Colorado.EDU> +To: linux-standards@banjo.concert.net +Subject: Re: Ok, we have been envoked. +In-Reply-To: Your message of Wed, 01 Apr 92 11:03:38 -0500. <00958734.4AA898A0.2220@csc.wcc.govt.nz> +Date: Tue, 31 Mar 92 17:49:09 MST +From: drew@romeo.cs.Colorado.EDU + + +-------- + + + I had a bit of trouble getting this message out (this is a VMS box - need + I say more:), so I apologize if you receive more than one copy. + + >... + >/dev/console should refer to the ENTIRE console, not just one virtual + >window. This is so that any error message that is printed to the console + >will come up on your screen (for the user at the machine itself) no matter + >which virtual console you are on. + >... + + What if something goes bananas and constantly writes messages to + /dev/console. You might have trouble getting typing in edgeways in + order to correct the situation (unless you have a terminal attached to + comm[0-3]). I guess you could have some way of enabing messages to + one set of vc's only, so that one or more would remain idle. + +Some one should implement a syslog daemon, and log all non-fatal kernel +messages from printk() there. I think that's my next project that I'll +get to next weeken d. + + + If there are going to many different types of controller perhaps I would + prefer a naming hierarchy. It would certainly make it easier to handle + variants (for example /svga/video-7/vram). Drives would be similar: + + /hd/wd/0 + /hd/wd/1 + /hd/wd/2 + /hd/scsi/0 + /hd/scsi/1 + /hd/scsi/2 + +1. /dev should be flat. A non-flat /dev breaks many programs. + +2. Names that long are heinous. + +3. Quick question : what chipset does an Amazing Technology + SVGA card use, A Star, ASKA, etc? There are so many + repackagings, OEM versions of cards, etc that + it is not even funny. The end user should not be + concerned with this mess, the drivers should sort it + out using something like probe, as I've done with the + SCSI drivers. We want ONE device name for all frame buffers, + ONE name for all SCSI disks, and so on. + +The device drivers should handle all the messy specifics, sorting out +what type of hardware you really have, like the BSD device driver's +probe(), or what I've done with the SCSI drivers. This eliminates +any need for cluttering the namespace with the inumerable +entries necessary to describe everything. + + +From linux-standards-request@banjo.concert.net Tue Mar 31 20:59:06 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <20942-2@banjo.concert.net>; Tue, 31 Mar 1992 20:57:11 -0500 +Received: from prg.oxford.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP + id <21282-0@sun2.nsfnet-relay.ac.uk>; Tue, 31 Mar 1992 22:02:30 +0100 +Received: from lucrece.robots (lucrece-gate.robots) by prg.oxford.ac.uk + id AA21948; Tue, 31 Mar 92 22:02:37 +0100 +Received: from robots.ox.ac.uk (diomedes.robots) + by uk.ac.oxford.robots (4.1/Robots 1.2m (20-Jun-90)) id AA00801; + Tue, 31 Mar 92 21:59:48 BST +Received: by robots.ox.ac.uk (4.1/robots.remoteV2.0) id AA11036; + Tue, 31 Mar 92 22:00:09 BST +Date: Tue, 31 Mar 92 22:00:09 BST +From: jon@robots.oxford.ac.uk +Message-Id: <9203312100.AA11036@diomedes.robots.ox.ac.uk> +To: linux-standards@banjo.concert.net +Subject: Re: Ok, we have been envoked. + + +From linux-standards-request@banjo.concert.net Tue Mar 31 21:30:16 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <20942-1@banjo.concert.net>; Tue, 31 Mar 1992 20:57:04 -0500 +Received: from prg.oxford.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP + id <21293-0@sun2.nsfnet-relay.ac.uk>; Tue, 31 Mar 1992 22:02:43 +0100 +Received: from lucrece.robots (lucrece-gate.robots) by prg.oxford.ac.uk + id AA21972; Tue, 31 Mar 92 22:03:05 +0100 +Received: from robots.ox.ac.uk (diomedes.robots) + by uk.ac.oxford.robots (4.1/Robots 1.2m (20-Jun-90)) id AA00804; + Tue, 31 Mar 92 22:00:22 BST +Received: by robots.ox.ac.uk (4.1/robots.remoteV2.0) id AA11040; + Tue, 31 Mar 92 22:00:43 BST +Date: Tue, 31 Mar 92 22:00:43 BST +From: jon@robots.oxford.ac.uk +Message-Id: <9203312100.AA11040@diomedes.robots.ox.ac.uk> +To: linux-standards@banjo.concert.net +Subject: Re: Ok, we have been envoked. + +My 4pence worth, + +->Ok, I'll throw my two cents worth in. +-> +->The easy ones first: :) +-> +->wd0 first winchester disk, entire disk +->wd0[abcd] first winchester disk, primary partitions +->wd0[e-z] first winchester disk, logical partitions +->wd[1-]* other winchester disks, etc. + +I like this, if we are using DOS partioning we shouldn't try and adopt +the BSD names, having c has the whole disk seems too arbitary to me. + +->fd0 first floppy drive, default format assigned by user +->fd0[a-g] first floppy drive, formats defined in floppy.c +->fd[1-N]* other floppy drives, etc. +-> +->lp0 first parallel printer port +->lp[1-N] other parallel printer ports + +All OK ny me. + +->Now, the hard ones. I've yet to see or come up with anything that I +->truely like, but the following are starting to grow on me. +-> +->vt0 (or ttyv0) current virtual terminal +->vt1 first virtual terminal +->vt[2-N] other virtual terminal + +I'd prefer +vtty0 (or ttyv0) first virtual terminal +vtty[1-N] (or ttyv[1-N]) second etc virtual terminals +... + +vtty (or ttyv) current virtual terminal + +This would seem more in tune with the tty naming (ie I'm currently using +/dev/tty1, but /dev/tty is always the current tty). + +->tty0 first serial port, assigned by the user +->tty[1-N] other serial ports, assigned by the user + +I'm fairly easy on these: +tty[a-d] seems fair (like Suns), but [0-3] is more in tune with the rest. +--- + +-Jon. <...!mcsun!ukc!robots.oxford.ac.uk!jon> + + + +From linux-standards-request@banjo.concert.net Tue Mar 31 22:27:50 1992 +Return-Path: +Received: from uu.psi.com by banjo.concert.net with SMTP (PP) + id <21264-0@banjo.concert.net>; Tue, 31 Mar 1992 22:27:14 -0500 +Received: from access.digex.com by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) + id AA02598; Tue, 31 Mar 92 22:06:05 -0500 +Received: by access.digex.com + id AA24736 (5.65b/IDA-1.4.3/Access-1.1 - Digital Express); + Tue, 31 Mar 92 16:42:54 -0500 +Date: Tue, 31 Mar 92 16:42:54 -0500 +From: "Joseph R. Massi" +Message-Id: <9203312142.AA24736@access.digex.com> +To: linux-standards@banjo.concert.net +Subject: [lalonde@qucis.queensu.ca: Com port naming] + +From: lalonde@qucis.queensu.ca (Paul Lalonde) +Date: Tue, 31 Mar 92 11:53:30 EST +To: linux-standards@banjo.concert.net +Subject: Com port naming + +Paul writes: + Ted writes: + >As for zero based versus one based for the serial ports, I would make + >the argument that (for better or for worse) due to long association with + >MS-DOS the hardware ports for the "first" serial port and the "second" + >serial port are COM1 and COM2. While renumbering them to be zero based + >may be the Unix Way, I think that it will cause way to much confusion. + >I would much rather see /dev/ttys1, /dev/ttys2, /dev/ttys3, and + >/dev/ttys4 for COM1, COM2, COM3, and COM4, respectively. + + I much prefer zero based ports. Dos is brain-dead and I see no reason + to keep it that way. Even the boards are labelled 0 and 1 (at least on + my box). So use /dev/ttys[0-3], and make links to /dev/com[1-4] if + you need them. Or even put the existence of the links in the standard + if you feel very stronly about them. But /dev/ttys[1-4] is just too + much of a nasty hybrid. + +I write: + +The argument that we follow the dos conventions is a powerful one, but +we are working on a unix system, not a dos system. Even the PC BIOS +zero-bases the com port numbers. I think the naming should be simple +and constistent with commercial unix systems. A super-user can always +create additional nodes with dos-like names (eg. /dev/com1) if he/she +wants to. I wouldn't, and I don't think the standard should. + +joe. + +P.S. I didn't participate in the full discussion of the directory +tree, but boy, this isn't easy... + + + + + + + + +joe. +------------------------------------------------------------------------------- +Joe Massi e-mail: jrmassi@access.digex.com +Columbia, MD packet radio: kb2jg@w3iwi.md.usa.noam... + USnail/Phone/Fax: ask + disclaimer: Who me? Claim something? + +From linux-standards-request@banjo.concert.net Wed Apr 1 06:32:47 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <22122-1@banjo.concert.net>; Wed, 1 Apr 1992 06:32:21 -0500 +Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk + via JANET with NIFTP id <5931-0@sun2.nsfnet-relay.ac.uk>; + Wed, 1 Apr 1992 09:37:39 +0100 +Message-id: <01 Apr 92 09:30:59 BST ZLSIIAL@UK.AC.MCC.CMS> +Date: Wed, 01 Apr 92 09:30:59 BST +From: LeBlanc@manchester-computing-centre.ac.uk +MyName: A. V. Le Blanc +To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@banjo.concert.net> +Subject: HD device names + + +I am not happy about the use of names such as hd2c for partition +c of disk 2. In particular, since the number of partitions on +one disk currently allowed by the kernel is 60, this naming +scheme cannot be carried out consistently. I know some people +will say that there is no practical chance of using more than +26 partitions on a given disk, but I am not so sure. + +With the increase in size of disks, and with the possibility of +using small partitions for small bits of the file system, I think +we ought not short sightedly choose a naming convention which +is likely to be awkward in the mid-term future. + +What is wrong with the current /dev/hda3? It may not be BSDish, +but many existing Unixes are not. And it does have the advantage +of existing! + + -- Owen + LeBlanc@mcc.ac.uk + +From linux-standards-request@banjo.concert.net Wed Apr 1 06:33:07 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <22122-3@banjo.concert.net>; Wed, 1 Apr 1992 06:32:40 -0500 +Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP + id <8909-0@sun2.nsfnet-relay.ac.uk>; Wed, 1 Apr 1992 11:10:10 +0100 +Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa20633; + 1 Apr 92 11:10 BST +Date: Wed, 01 Apr 92 11:10:05 +0100 +From: Damiano Bolla +To: linux-standards@banjo.concert.net +Subject: Devices + + +> The drivers should take care of this for you, like the SCSI drivers +> do, so that no matter what SCSI adapter you have (currently, +> Ultrastor and Seagate adapters are supported, RSN Adaptec, and soon +> DTC and CSC adapters) do, you only have one /dev/sd* set of devices, +> and one set of major/minor numbers to deal with. + +Umhhh, the point is that people might want to have in the same system +A wd drive +A Scsi drive +A colorado tape +A soundblaster + +or any other kind of hardware combination.... +Believe me the amount of rubbish for PC is MUCH more that an average +workstation can even dream :-) +You can't leave it to the kernel ONLY,you need some sort of way to +tell to the kernel what to use. + +You can do this at install time by creating the devices using different +major and minor depending ont he hardware you have. +OR you can have all possible combination of stuff as a preinstalled +device name. + +If you choose the second method you need to make distinctions. + +I think that this discussion showed that the task will be a bit hard.... + +What about s shell script that create devices on demand ? +Something like + +makedevice scsi + +Create the scsi devices + +makdevice colorado + +Create the colorado devices + +This will keep the /dev/directory short..... + +Anyway the device naming blues will not finish with this system +The device names MUST be unique for ANY possible hardware combination +After all you newer Know what you are going to install ..... + +I like the idea of +[device type][device brand][attributes ] + +Each part being a maximum of three chars. +Ex: + +fdscsi0 +fdwd0 +mtcolr0 +flp1.2mb The 1.2mb floppy +flp1.4mb The 1.44 mb floppy +flp2.0mb The future 2.0 mb ?.... + +and so on.... + +For the serial lines it hink it will be nice to stay with + +ttys1 +ttys2 + +and so on + +the pty can be something +ttyp1 The slave part have p since s is used by the serial ) +ttyp2 + +and + +ttym1 The master part of a pty +ttym2 + +Remembar, it the thing is cannot be extended sooner or later (by Murphy) +you will hit the limit. Therefore, it is better if the standard +can be expanded without creating conflicts. + +Damiano + +From linux-standards-request@banjo.concert.net Wed Apr 1 07:05:16 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <22122-2@banjo.concert.net>; Wed, 1 Apr 1992 06:32:28 -0500 +Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk + via JANET with NIFTP id <7261-0@sun2.nsfnet-relay.ac.uk>; + Wed, 1 Apr 1992 10:19:39 +0100 +Message-id: <01 Apr 92 09:44:57 BST ZLSIIAL@UK.AC.MCC.CMS> +Date: Wed, 01 Apr 92 09:44:57 BST +From: LeBlanc@manchester-computing-centre.ac.uk +MyName: A. V. Le Blanc +To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@banjo.concert.net> +Subject: Floppy disks + + +While we're on the subject of renaming devices, floppy disks +are long overdue for a replacement -- the MINIX names are +unmemorable and unsystematic. The suggestion has been raised +that we use fd0a, where 0 is the drive number and a is a format +defined somewhere or other (specifically in floppy.c). + +This has a clean, tidy look, but there is a slight disadvantage: +remembering which format code letter refers to a disk of a given +size and density in a given drive. Is it possible to suggest -- +just to prompt a reaction -- something like this: + + fd0d5 Drive 0, 5.25 inch disk, double density. + fd1q3 Drive 1, 3.5 inch disk, quad density. + fd0h3 Drive 0, 3.5 inch disk, high density. + +If this scheme were adopted, we should have the following table: + + Old New Size bytes tracks sectors + PS0 fd0h3 3.5 1.4mb 80 18 + at0 fd0h5 5.25 1.2mb 80 15 + ps0 fd0q3 3.5 720kb 80 9 + qh0 fd0q5 5.25 720kb 80 9 + ? fd0d3 3.5 360kb 40 9 + pc0 fd0d5 5.25 360kb 40 9 + +This takes into account the various disks, but ignores the +drive capacity; I don't know what problems this would cause. +But in any case, I should find the [qdh][35] system much +easier to use and remember than any [a-h] system, which would +always involve digging out a table. + + -- Owen + LeBlanc@mcc.ac.uk + +From linux-standards-request@banjo.concert.net Wed Apr 1 11:10:19 1992 +Return-Path: +Received: from QUCIS.QueensU.CA by banjo.concert.net with SMTP (PP) + id <22868-0@banjo.concert.net>; Wed, 1 Apr 1992 11:09:55 -0500 +Received: from qusunb.qucis.queensu.ca by qucis.queensu.ca (4.1/SMI-4.1-qs1.2) + id AA25648; Wed, 1 Apr 92 11:09:58 EST +From: lalonde@qucis.queensu.ca (Paul Lalonde) +Received: by qusunb.qucis.queensu.ca (4.1/SMI-4.0-qc1.1) id AA22371; + Wed, 1 Apr 92 11:09:55 EST +Date: Wed, 1 Apr 92 11:09:55 EST +Message-Id: <9204011609.AA22371@qusunb.qucis.queensu.ca> +To: linux-standards@banjo.concert.net +Subject: HD naming + +One more thing I've not seen mentionned about hard drive naming: +How about the raw partitions? (partition as a character file) + +I might suggest that given /dev/[wd|sd|hd][0-n][a-z] for the block +devices that we might get /dev/[wd|sd|hd]r[0-n][a-z] for the character +devices. + +(yes I use these occasionally on other unix boxes when I need to +repair damaged file systems. Comming to think of it...does Linux +have support for raw drive access? Have to check when I get home.) + + Paul + + + Paul A. Lalonde Internet: lalonde@qucis.queensu.ca + Home Phone: (613)549-0605 Work Phone: (613)545-6754 + + "The only true law is that which leads to freedom" + - Richard Bach, _Jonathan Livingston Seagull_ + +From linux-standards-request@banjo.concert.net Wed Apr 1 12:21:53 1992 +Return-Path: +Received: from ladymacb.cs.colorado.edu by banjo.concert.net with SMTP (PP) + id <23247-0@banjo.concert.net>; Wed, 1 Apr 1992 12:21:11 -0500 +Received: from localhost by ladymacb.cs.Colorado.EDU with SMTP + id AA02946 (5.65c/IDA-1.4.4 for linux-standards@banjo.concert.net); + Wed, 1 Apr 1992 10:17:24 -0700 +Message-Id: <199204011717.AA02946@ladymacb.cs.Colorado.EDU> +To: Damiano Bolla , linux-standards@banjo.concert.net +Subject: Re: Devices +In-Reply-To: Your message of Wed, 01 Apr 92 11:10:05 +0100. <199204011154.AA14075@torreys.cs.colorado.edu> +Date: Wed, 01 Apr 92 10:17:22 MST +From: drew@ladymacb.cs.Colorado.EDU + + +-------- + + + > The drivers should take care of this for you, like the SCSI drivers + > do, so that no matter what SCSI adapter you have (currently, + > Ultrastor and Seagate adapters are supported, RSN Adaptec, and soon + > DTC and CSC adapters) do, you only have one /dev/sd* set of devices, + > and one set of major/minor numbers to deal with. + + Umhhh, the point is that people might want to have in the same system + A wd drive + A Scsi drive + A colorado tape + A soundblaster + +Yes, but you don't need a + +/dev/sdadaptec[0-6] +/dev/sdseagate[0-6], etc. + +The point is for "similar" devices, they should have the same name iregardless +of implementation. IE SCSI disk adaptec , seagate, etc are all the same. + +QIC-02 tapes from Colorado, Wantek, etc are all the same. + +ST506 drives, be they IDE, MFM, RLL, ESDI are the same. + + You can't leave it to the kernel ONLY,you need some sort of way to + tell to the kernel what to use. + + What about s shell script that create devices on demand ? + Something like + + makedevice scsi + + Create the scsi devices + + makdevice colorado + + Create the colorado devices + + This will keep the /dev/directory short..... + +This would be nice. Maybe we should have a nice, interactive install +script (see Larry Wall's configure script for Perl for an example) + + Anyway the device naming blues will not finish with this system + The device names MUST be unique for ANY possible hardware combination + After all you newer Know what you are going to install ..... + + I like the idea of + [device type][device brand][attributes ] + ^^^^^ +I've been saying that this field is undesireable where multiple +devices of the same type will not be installed simultaneously, and that +even if they are there should probably just be more minor numbers off of +the same device, ie + +/dev/snd0 + +/dev/snd1 +for the first two sound boards installed. + + + Each part being a maximum of three chars. + Ex: + + fdscsi0 + fdwd0 + mtcolr0 + +What's wrong with "normal" names, like those used on any other system? +/dev/sd - scsi disks +/dev/st - scsi tapes +/dev/mt - magnetic tapes +/dev/fd - floppy disks +/dev/hd - "normal" hard disks + +etc. + + flp1.2mb The 1.2mb floppy + flp1.4mb The 1.44 mb floppy + flp2.0mb The future 2.0 mb ?.... + +A human readable size identified for the sloppy disk IS a good idea. +However, I think + +/dev/fd[drive no]d{1440, 1200, 720, 360, 2880} +may work better and be more asthetically pleasing. + +Another note : 2.0mb floppies exist and nearly everyone has one in +his computer these days - 2.0mb disks are unformatted 1.44's + + For the serial lines it hink it will be nice to stay with + + ttys1 + ttys2 + + and so on + +Agreed. + + the pty can be something + ttyp1 The slave part have p since s is used by the serial ) + ttyp2 + + and + + ttym1 The master part of a pty + ttym2 + + Remembar, it the thing is cannot be extended sooner or later (by Murphy) + you will hit the limit. Therefore, it is better if the standard + can be expanded without creating conflicts. + + Damiano + +That's abnormal. We want to stick with "normal" naming conventions - ie +/dev/ttyp +/dev/ptyp + +and if numbers run out + +dev/ttyq +/dev/ptyq + + +From linux-standards-request@banjo.concert.net Wed Apr 1 14:22:07 1992 +Return-Path: +Received: from twok.ods.com by banjo.concert.net with SMTP (PP) + id <23751-0@banjo.concert.net>; Wed, 1 Apr 1992 14:21:41 -0500 +Received: by istwok.ods.com id AA07197 (5.65c/IDA-1.3.5); + Wed, 1 Apr 1992 13:24:39 -0600 +From: David Engel +Message-Id: <199204011924.AA07197@istwok.ods.com> +Subject: Various Replies +To: linux-standards@banjo.concert.net +Date: Wed, 1 Apr 92 13:24:37 CST +X-Mailer: ELM [version 2.3 PL11] + +>From: jon@robots.ox.ac.uk +>vtty[1-N] (or ttyv[1-N]) second etc virtual terminals +>vtty (or ttyv) current virtual terminal +> +>This would seem more in tune with the tty naming (ie I'm currently using +>/dev/tty1, but /dev/tty is always the current tty). +> +>->tty0 first serial port, assigned by the user +>->tty[1-N] other serial ports, assigned by the user +> +>I'm fairly easy on these: +>tty[a-d] seems fair (like Suns), but [0-3] is more in tune with the rest. + +I'd be perfectly happy with something simple like tty[0-N] for virtual +consoles and tty[a-d] for serial ports. However, someone mentioned the +possibility of smart serial cards with more than 4 serial ports. Perhaps +we should just go with tty[a-d] and let those with smart cards devise +there own naming scheme. + +========================================================================= + +>From: LeBlanc@manchester-computing-centre.ac.uk +> +>I am not happy about the use of names such as hd2c for partition +>c of disk 2. In particular, since the number of partitions on +>one disk currently allowed by the kernel is 60, this naming +>scheme cannot be carried out consistently. I know some people +>will say that there is no practical chance of using more than +>26 partitions on a given disk, but I am not so sure. +> +>With the increase in size of disks, and with the possibility of +>using small partitions for small bits of the file system, I think +>we ought not short sightedly choose a naming convention which +>is likely to be awkward in the mid-term future. + +I'm not entirely happy with it either. I'd prefer to have wd0[a-d] +for primary partitions and something like wd0[a-d][0-9|a-z] for +logical partitions, but the kernel doesn't number partitions that +way. + +BTW, is anyone else concerned about how logical partitions are, in +effect, dynamically numbered? Creating or deleting a logical partitio, +even for another OS, could potentially raise havoc with your Linux +system by renumbering all of the logical partitions. + +>What is wrong with the current /dev/hda3? It may not be BSDish, +>but many existing Unixes are not. And it does have the advantage +>of existing! + +There's nothing really "wrong" with it. I prefer wd0a (or hd0a) because +it's consistent with the other devices names (ie. multiple devices of +the same type are distinguished using a digit instead of a letter). + +========================================================================= + +>From: LeBlanc@manchester-computing-centre.ac.uk +> +>This has a clean, tidy look, but there is a slight disadvantage: +>remembering which format code letter refers to a disk of a given +>size and density in a given drive. Is it possible to suggest -- +>just to prompt a reaction -- something like this: +> +> fd0d5 Drive 0, 5.25 inch disk, double density. +> fd1q3 Drive 1, 3.5 inch disk, quad density. +> fd0h3 Drive 0, 3.5 inch disk, high density. + +Hmm, I think I like it. But how about dropping the [35] part and +just differentiate them by the density? An install or makedev script +could ask the user whether the drive is 3.5" or 5.25" and setup the +right minor device numbers. Then we would have fd0[dqh] with fd0 +being the user-defined default (highest) density. + +-David +-- +David Engel Optical Data Systems, Inc. +david@ods.com 1101 E. Arapaho Road +(214) 234-6400 Richardson, TX 75081 + +From LINUX-STANDARDS-request@banjo.concert.net Thu Apr 2 14:21:13 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <27870-0@banjo.concert.net>; Thu, 2 Apr 1992 14:20:47 -0500 +Received: from sirius.ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP + id <3590-0@sun2.nsfnet-relay.ac.uk>; Thu, 2 Apr 1992 09:12:36 +0100 +Date: Thu, 2 Apr 92 9:12 BST +From: Damiano Bolla +To: LINUX-STANDARDS <@nsfnet-relay.ac.uk:LINUX-STANDARDS@BANJO.CONCERT.net> +Subject: Porting Software to Linux + +Hello + +This article contains some suggestions for all of you that want to port +software to Linux and asck some questions about standards. + +First: +My system is: gcc1.40 (the new one with the new library) +kernel 95a and the rest is as usual :-) + +I ported the ghostscript2.4 to Linux, I had to since I have a strange printer. +I defined SYVR4 for my compile +I had only two problems: +1) The field st_bloks in the file sys/stat.h is missing +2) The file malloc.h is missing +NOTHING more ! + +The point now is this: +Can SOMEBODY please modify the include files in the DISTRIBUTION so +they are consistent with SYSVr4 ? +This will make Linux MORE and MORE "standard" !!!! + +The idea is that everybody that compile uses either +-DSYSVR4 +or +-DPOSIX +or +-DSYSV + +They keep trak of the incompatibility they find and report them in this + maillist. SOmebody then will update the include files so the reported +problem will not appear again ! + +Damiano + +P.S. It really would be nice if we had a different subtree for each new linux +release. What I am asking is that the ftp-man put the NEW stuff and ONLY +the new stuff under the current release. By this way we immediatly know +what is new instead of downloading megabytes and then find that we already +had the pakage.... +Am I asking too much ? + + +From linux-standards-request@banjo.concert.net Thu Apr 2 15:02:48 1992 +Return-Path: +Received: from nic.stolaf.edu by banjo.concert.net with SMTP (PP) + id <28039-0@banjo.concert.net>; Thu, 2 Apr 1992 15:02:18 -0500 +Received: from amcl11.math.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA07794; + Thu, 2 Apr 92 14:01:57 CST +Date: Thu, 2 Apr 92 14:01:57 CST +From: johnsonm@stolaf.edu (Michael K. Johnson) +Message-Id: <9204022001.AA07794@stolaf.edu> +Received: by amcl11.math.stolaf.edu (4.1/SMI-4.1) id AA00828; + Thu, 2 Apr 92 14:01:51 CST +To: CET601@sirius.ukc.ac.uk +Cc: linux-standards@banjo.concert.net +In-Reply-To: Damiano Bolla's message of Thu, 2 Apr 92 9:12 BST <9204021923.AA07066@stolaf.edu> +Subject: Porting Software to Linux + + Date: Thu, 2 Apr 92 9:12 BST + From: Damiano Bolla + + The point now is this: + Can SOMEBODY please modify the include files in the DISTRIBUTION so + they are consistent with SYSVr4 ? + This will make Linux MORE and MORE "standard" !!!! + + The idea is that everybody that compile uses either + -DSYSVR4 + or + -DPOSIX + or + -DSYSV + +Um, we are not trying to create a sysVr4 clone (heaven forbid). We +_are_ working on POSIX compatibility. + +Please, not sysvr4. it's just too big. All things to all people, you +know. That certainly shouldn't describe linux. Nor should the need +for huge disks... + +As far "the include files in the DISTRIBUTION" go, well, it depends on +your compiler. There really is no standard right now -- that's under +development. Wait for gcc 2.1/2.2 and the ABC release if you are not +comfortable with a little playing with such things. + +michaelkjohnson +johnsonm@stolaf.edu + + +From LINUX-STANDARDS-request@banjo.concert.net Thu Apr 2 17:00:14 1992 +Return-Path: +Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP) + id <28356-0@banjo.concert.net>; Thu, 2 Apr 1992 16:37:14 -0500 +Received: by sumax.seattleu.edu id AA14993 (5.65a/IDA-1.4.2 + for LINUX-STANDARDS@BANJO.CONCERT.net); Thu, 2 Apr 92 13:37:56 -0800 +Date: Thu, 2 Apr 92 13:37:56 -0800 +From: Chuck Boyer +Message-Id: <9204022137.AA14993@sumax.seattleu.edu> +To: CET601@sirius.ukc.ac.uk, LINUX-STANDARDS@BANJO.CONCERT.net +Subject: Re: Porting Software to Linux + +No, you are not asking too much. Somebody needs to take the time to +do this, now. Everything of each new release in the same directory, +also a text file explaining this. +chuck + +From LINUX-STANDARDS-request@banjo.concert.net Thu Apr 2 17:18:22 1992 +Return-Path: +Received: from banjo.concert.net by banjo.concert.net + id <28468-0@banjo.concert.net>; Thu, 2 Apr 1992 17:17:42 -0500 +Subject: Re: Porting Software to Linux +To: boyer@seattleu.edu (Chuck Boyer) +Date: Thu, 2 Apr 92 17:17:38 EST +Cc: CET601@sirius.ukc.ac.uk, LINUX-STANDARDS@BANJO.CONCERT.net +In-Reply-To: <9204022137.AA14993@sumax.seattleu.edu>; from "Chuck Boyer" at Apr 2, 92 1:37 pm +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@banjo.concert.net + +In previous mail, Chuck Boyer said something like: + +> No, you are not asking too much. Somebody needs to take the time to +> do this, now. Everything of each new release in the same directory, +> also a text file explaining this. + +Hopefully by the end of next week (before my vacation), I will have put +together a definitive release. It will contain all of the sources I have +put together for .95a, including things I have done myself, and the (three?) +contributions I have so-far. + +If you have anything to contribute, please let me know ASAP. + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From LINUX-STANDARDS-request@banjo.concert.net Thu Apr 2 19:08:41 1992 +Return-Path: +Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP) + id <28741-0@banjo.concert.net>; Thu, 2 Apr 1992 19:08:02 -0500 +Received: by sumax.seattleu.edu id AA03881 (5.65a/IDA-1.4.2 + for LINUX-STANDARDS@BANJO.CONCERT.net); Thu, 2 Apr 92 16:08:47 -0800 +Date: Thu, 2 Apr 92 16:08:47 -0800 +From: Chuck Boyer +Message-Id: <9204030008.AA03881@sumax.seattleu.edu> +To: abc@banjo.concert.net, boyer@seattleu.edu +Subject: Re: Porting Software to Linux +Cc: CET601@sirius.ukc.ac.uk, LINUX-STANDARDS@BANJO.CONCERT.net + +I uploaded at 'tsx-11.mit.edu' in /incoming/guide.1a which is the +pre-release of the final draft of the (DOS) BEGINNER'S GUIDE TO +LINUX/unix that I will update as per everyone's instructions, +comments, on Sunday, April 5. This will be my final update/draft +of the guide as it is now known. It will be absorbed by other persons +who are putting together a 'definitive' guide. I will probably go +on to write up a beginner's guide in a different format, much like +published works. + +I wish only that a document were provided, or in the FAQ, what +files contain what, for instance, what is it?; filutils.tar.Z, +binutils.tar.Z, newutils.tar.Z, ... (well I haven't checked just +now, but do you know what I mean?), so that 'what's in each of +those files are listed somewhere.... so people would know. +and people are told in news notes that the missing utility that are +needing is in /OLD/utilbin.tar.Z for instance. +chuck +oh, also; + +wish list: + +already created /dev/at0 (it 'is' there) + /dev/atlow (for 360K) + /dev/at1 + /dev/at1low (for 720K) + +or documentation on how to mknod /dev/at1low........ etc.... +thanks +chuck + +From LINUX-STANDARDS-request@banjo.concert.net Thu Apr 2 19:57:21 1992 +Return-Path: +Received: from nic.stolaf.edu by banjo.concert.net with SMTP (PP) + id <28812-0@banjo.concert.net>; Thu, 2 Apr 1992 19:56:54 -0500 +Received: from amcl12.math.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA03283; + Thu, 2 Apr 92 18:55:15 CST +Date: Thu, 2 Apr 92 18:55:15 CST +From: johnsonm@stolaf.edu (Michael K. Johnson) +Message-Id: <9204030055.AA03283@stolaf.edu> +Received: by amcl12.math.stolaf.edu (4.1/SMI-4.1) id AA26832; + Thu, 2 Apr 92 18:55:10 CST +To: boyer@seattleu.edu, LINUX-STANDARDS@BANJO.CONCERT.net, + Linux-activists@joker.cs.hut.fi, linux-activists@news-digests.mit.edu +In-Reply-To: Chuck Boyer's message of Thu, 2 Apr 92 16:08:47 -0800 <9204030008.AA03881@sumax.seattleu.edu> +Subject: Porting Software to Linux + + Date: Thu, 2 Apr 92 16:08:47 -0800 + From: Chuck Boyer + + I uploaded at 'tsx-11.mit.edu' in /incoming/guide.1a which is the + pre-release of the final draft of the (DOS) BEGINNER'S GUIDE TO + LINUX/unix that I will update as per everyone's instructions, + comments, on Sunday, April 5. + +tsx-11.mit.edu:/pub/linux/docs/guide.1a + +michaelkjohnson +johnsonm@stolaf.edu + + + +From linux-standards-request@banjo.concert.net Fri Apr 3 09:40:39 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <00596-0@banjo.concert.net>; Fri, 3 Apr 1992 09:40:13 -0500 +Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk + via JANET with NIFTP id <11767-0@sun2.nsfnet-relay.ac.uk>; + Thu, 2 Apr 1992 13:42:15 +0100 +Message-id: <02 Apr 92 13:17:33 BST ZLSIIAL@UK.AC.MCC.CMS> +Date: Thu, 02 Apr 92 13:17:33 BST +From: ZLSIIAL@cms.manchester-computing-centre.ac.uk +MyName: A. V. Le Blanc +To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@banjo.concert.net> +Subject: flat /dev, fd names + + +Some discussion has been going on about the format of the /dev +directory. Two notes thus far have surprised me by saying that +the presence of subdirectories under /dev would break many +programs. I am surprised at this, since most of the systems I +use have subdirectories under /dev, and I don't know of any +program that I ported that objected. + +/dev can be a mess, particularly if we expect it to contain +all legal device names. Once you start having scads of pseudo +terminals for various purposes, floppy disks, hard disks, etc, +it becomes difficult to find things in the directory, and +directory listings become too unwieldy. The existing software +which refers to /dev a great deal will surely be compilable +on other systems which do not have 'flat' /dev, if it is written +at all portably. And surely the fundamental commands are those +which are most likely to mess about with /dev/xxx; as long as +we keep, e.g., /dev/tty, we shouldn't have any big problems. + +Recently I wrote a note to this list which suggested a naming scheme +for floppy disks. As this note seems to have disappeared (it will +probably appear here tomorrow), let me repeat the suggestion. + +The name of a floppy disk device (at least in 'flat' /dev) would be +fd[drive][density][disksize], where [drive] is 0-3, [density] is +'d', 'q', or 'h', and [disksize] is '3' or '5'. This seems to me +better than the fd[drive][codeletter] scheme, since I would have +as much difficulty remembering the code letters as I have now +with the hopeless Minix names. + + -- Owen + LeBlanc@mcc.ac.uk + +From linux-standards-request@banjo.concert.net Fri Apr 3 10:53:25 1992 +Return-Path: +Received: from banjo.concert.net by banjo.concert.net + id <00778-0@banjo.concert.net>; Fri, 3 Apr 1992 10:52:50 -0500 +Subject: Standard Proposal for Device Naming +To: linux-standards@banjo.concert.net +Date: Fri, 3 Apr 92 10:52:45 EST +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@banjo.concert.net + + +Well, I have put my brain in gear and after hearing all of the discussion, have +come up with a proposal. + +General form: + + Western Digital (IDE/RLL/MFM etc) Hard Drives + /dev/{r}wd[C][N][P] + r == if specified, designates a raw (character) device + C == [a-z] Controller designation [a=first, b=second, etc] + N == [0-9] Disk Drive Number on Controller + P == [a-z] Partition number (if not given, designates entire + disk) + + Examples: + /dev/wda0 First Controller, Drive 0, entire disk + /dev/rwad0 First Controller, Drive 0, Entire disk + Raw device + /dev/wda0a First Controller, Drive 0, partition 1 + + Non-SCSI Magnetic Tape Devices + /dev/{r}mt[C][N] + r == if specified, designates a raw (character) device + C == [a-z] Host Adapter [a=floppy controller, b=first + add-on board, etc] + N == [0-9] Tape Device number on host adapter + + Examples: + /dev/rmta0 Raw Tape device, using tape device 0 on + the floppy controller + /dev/rmtb0 Raw Tape device, using tape device 0 on + add-on board + + SCSI Disk Devices + /dev/{r}sd[C][N][L][P] + r == if specified, designates a raw (character) device + C == [a-z] Host Adapter [a=first, b=second, etc] + N == [0-7] SCSI ID of Disk + L == [0-7] Logical Unit Number of device + P == [a-z] Partition number (if not given, designates entire + disk) + + Examples: + /dev/sda00a First Host Adapter, + SCSI ID 0, Lun 0, partition a + /dev/sdb10 Second Host Adapter, + SCSI ID 1, Lun 0, entire disk + + SCSI Tape Devices + /dev/{r}st[C][N][L] + r == if specified, designates a raw (character) device + C == [a-z] Host Adapter [a=first, b=second, etc] + N == [0-7] SCSI ID of Tape Unit + L == [0-7] Logical Unit Number of device + + Examples: + /dev/rsta40 Raw SCSI Tape, First Host Adapter, + SCSI ID 4, Lun 0 + + Floppy Disk Devices + /dev/{r}fd[N][S][D] + r == if specified, designates a raw (character) device + N == [0-1] Floppy disk number [0=a, 1=b] + S == [3,5,8] Disk Size in inches (rounded) + D == [sdq] Density (capacity depends on S and D) + h = "high" density + l = "low" density + + Examples: + /dev/fd03h Drive A:, High Density, 3.5" disk (1.44Mb) + /dev/fd03l Drive A:, Low Density, 3.5" disk (720Mb) + /dev/fd15h Drive B:, High Density, 5.25" disk (1.2Mb) + /dev/fd15l Drive B:, Low Density, 5.25" disk (360k) + + Console Device + /dev/console + "Master" console == /dev/vc1 unless otherwise set + + Current tty + /dev/tty + standard UNIX device, your "current" terminal + + Virtual Console Devices + /dev/vc[N] + N == [1-8] Virtual Console number (number represents FKey + that corresponds to given VC) + + Pseudo Terminals + /dev/ttyp[N] + /dev/ptyp[N] + N == [00-99] Pseudo Terminal number. The t and p devices + represent the master and slave side of + the pseudo terminal. + + "Standard" Serial Devices + /dev/ttys[N] + N == [0-3] Serial device corresponding to DOS COM1: - COM4: + + Intelligent Serial Devices [add-on boards] + /dev/tty[T][N] + T == [a-z] Board Identifier [a=first, b=second, etc] + N == [00-99] Serial port number. + + Examples: + /dev/ttya00 == first serial port on first add-on controller board. + /dev/ttyb16 == 17th serial port on second add-on controller board. + + Parallel devices + /dev/par[N] + N == [0-2] Parallel port responding to DOS LPT1 - LPT3 + +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux-standards-request@banjo.concert.net Fri Apr 3 11:22:31 1992 +Return-Path: +Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP) + id <00904-0@banjo.concert.net>; Fri, 3 Apr 1992 11:21:56 -0500 +Received: by sumax.seattleu.edu id AA32168 (5.65a/IDA-1.4.2 + for linux-standards@banjo.concert.net); Fri, 3 Apr 92 08:22:43 -0800 +Date: Fri, 3 Apr 92 08:22:43 -0800 +From: Chuck Boyer +Message-Id: <9204031622.AA32168@sumax.seattleu.edu> +To: ZLSIIAL@cms.mcc.ac.uk, linux-standards@banjo.concert.net +Subject: Re: flat /dev, fd names + +What's terribly wrong with +/dev/at0 +/dev/xt0 +/dev/at1 +/dev/xt1 +for 'beginner's' it makes 'sense.' My point is that for everyone +else (hackers, programmers...etc.) they know enough, are smart +enough to change things, and it's not that big of a hastle. 'But' +for beginners, and explaining to beginners, logic, simple, at/xt +seems the 'obvious' choice. fd1h5 is okay too I guess, I concede, +but it's not so transparent... it's okay though. +chuck + +From linux-standards-request@banjo.concert.net Fri Apr 3 12:37:49 1992 +Return-Path: +Received: from twok.ods.com by banjo.concert.net with SMTP (PP) + id <01236-0@banjo.concert.net>; Fri, 3 Apr 1992 12:37:05 -0500 +Received: by istwok.ods.com id AA18934 (5.65c/IDA-1.3.5); + Fri, 3 Apr 1992 11:40:17 -0600 +From: David Engel +Message-Id: <199204031740.AA18934@istwok.ods.com> +Subject: Re: Standard Proposal for Device Naming +To: abc@banjo.concert.net (Alan B Clegg) +Date: Fri, 3 Apr 92 11:40:16 CST +Cc: linux-standards@banjo.concert.net +In-Reply-To: <199204031605.AA18481@istwok.ods.com>; from "Alan B Clegg" at Apr 3, 92 10:52 am +X-Mailer: ELM [version 2.3 PL11] + +> +> +> Well, I have put my brain in gear and after hearing all of the discussion, +> have come up with a proposal. + +All in all, I think I could live with it. I still have the following +comments, however: + +> Floppy Disk Devices +> /dev/{r}fd[N][S][D] +> r == if specified, designates a raw (character) device +> N == [0-1] Floppy disk number [0=a, 1=b] +> S == [3,5,8] Disk Size in inches (rounded) +> D == [sdq] Density (capacity depends on S and D) +> h = "high" density +> l = "low" density + +I think we should stick with the standard density names, ie. d=double, +q=quad and h=high. + +I would like to see the standard explicitly allow (maybe even encourage) +users to add generic, shorthand, localized names/links for the devices +used on their system. Examples might be: + + /dev/hd2b second primary partition on my third hard disk + /dev/fd1d double density diskette in my second floppy drive + /dev/tty03 my fourth serial port + +This would create a definitive set of device names with consistent major/ +minor numbers across all Linux systems, but also provides standard names +for people like me who don't want to specify the controller number and +size of media every time we reference a device. + +-David +-- +David Engel Optical Data Systems, Inc. +david@ods.com 1101 E. Arapaho Road +(214) 234-6400 Richardson, TX 75081 + +From linux-standards-request@banjo.concert.net Fri Apr 3 12:43:57 1992 +Return-Path: +Received: from banjo.concert.net by banjo.concert.net + id <01307-0@banjo.concert.net>; Fri, 3 Apr 1992 12:43:02 -0500 +Subject: Re: Standard Proposal for Device Naming +To: david@istwok.ods.com (David Engel) +Date: Fri, 3 Apr 92 12:42:52 EST +Cc: linux-standards@banjo.concert.net +In-Reply-To: <199204031740.AA18934@istwok.ods.com>; from "David Engel" at Apr 3, 92 11:40 am +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@banjo.concert.net + +In previous mail, David Engel said something like: + +> All in all, I think I could live with it. I still have the following +> comments, however: + +Thanks.. + +> > Floppy Disk Devices + +> I think we should stick with the standard density names, ie. d=double, +> q=quad and h=high. + +How many really use all three? Are there still 720k floppy disks around? +Why define more than we need? If the need is there, I agree (infact, my +original draft [internal use only] had Low, Double, and Quad, until I tried +to find a use for all three... LET ME KNOW! + +> I would like to see the standard explicitly allow (maybe even encourage) +> users to add generic, shorthand, localized names/links for the devices +> used on their system. Examples might be: +> +> /dev/hd2b second primary partition on my third hard disk +> /dev/fd1d double density diskette in my second floppy drive +> /dev/tty03 my fourth serial port + +I disagree. This leads to confusion (ESPECIALY ON SERIAL DEVICES) of locking +mechanisms. Is every version of UUCP, kermit and pcomm supposed to know +that /dev/tty03 == /dev/ttys3 when creating /usr/spool/uucp/LCK..tty03? + +This is a __MAJOR__ problem. I recommend that we find one set of devices and +make that the *STANDARD* and let people evolve into using them. We did the +same for the directory tree (not that I have seen any use of it, but..) and +everyone seems to get along OK with it... + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux-standards-request@banjo.concert.net Fri Apr 3 13:14:35 1992 +Return-Path: +Received: from nic.stolaf.edu by banjo.concert.net with SMTP (PP) + id <01463-0@banjo.concert.net>; Fri, 3 Apr 1992 13:13:09 -0500 +Received: from amcl10.math.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA20891; + Fri, 3 Apr 92 12:13:00 CST +Date: Fri, 3 Apr 92 12:13:00 CST +From: johnsonm@stolaf.edu (Michael K. Johnson) +Message-Id: <9204031813.AA20891@stolaf.edu> +Received: by amcl10.math.stolaf.edu (4.1/SMI-4.1) id AA07102; + Fri, 3 Apr 92 12:13:00 CST +To: linux-standards@banjo.concert.net +In-Reply-To: David Engel's message of Fri, 3 Apr 92 11:40:16 CST <199204031740.AA18934@istwok.ods.com> +Subject: Standard Proposal for Device Naming + + From: David Engel + + > Floppy Disk Devices + > /dev/{r}fd[N][S][D] + > r == if specified, designates a raw (character) device + > N == [0-1] Floppy disk number [0=a, 1=b] + > S == [3,5,8] Disk Size in inches (rounded) + +What about the 2 inch floppies in some laptops? We ignoring them? +Ok, fine. That's a good idea, actually, since they never took off and +I think act like 3.5's at quad density anyway. (someone correct me if +I'm wrong...) + + > D == [sdq] Density (capacity depends on S and D) + > h = "high" density + > l = "low" density + + I think we should stick with the standard density names, ie. d=double, + q=quad and h=high. + +now also e=extra, for the 2.88. Linux will support them someday, if +it doesn't already... (I don't have any... wouldn't know) + + I would like to see the standard explicitly allow (maybe even encourage) + users to add generic, shorthand, localized names/links for the devices + used on their system. Examples might be: + +Of course. That's the thing that I think gets missed as we discuss +all this. There has been talk as if the device name has to be instantly +transparent to every user, even if that requires a name 20 char's +long. Well, I'm exagerating, but really, we need a standard that +makes sense to the hacker and will be reasonble to program with, not +one that is instantly transparent to joe dos user -- That is what +documentation is for. I am not saying that we should unnecessarily +make things difficult -- not by any means -- but that most users +should not have to deal with /dev names very often, and that when they +do, they shouldn't have to type extremely long names. + +This most recent proposal of Alan's I think fits the bill very nicely. +We need an absolutely standard and reasonable orthogonal system of +naming, and this provides it. I am certainly not attacking joe dos +user, as that is where I have come from too, though with some exposure +to unix as a standard user for the last few years. And in the +documentation, I am putting a high priority on reaching joe dos user. +I just think... Well, re-read the last paragraph :-). + +One small suggestion/idea: + +should we specify a link from /dev/lp to whatever the "standard +printer" that the user wants to use normally is? That way, things +print on /dev/lp without having to be configured to use +/dev/par[something] or /dev/ttys[something] for those with serial +printers. I imagine that the default value of this link would be a +link to the first par port... + +Comments? + +michaelkjohnson +johnsonm@stolaf.edu + +From linux-standards-request@banjo.concert.net Fri Apr 3 15:10:46 1992 +Return-Path: +Received: from twok.ods.com by banjo.concert.net with SMTP (PP) + id <02473-0@banjo.concert.net>; Fri, 3 Apr 1992 15:09:59 -0500 +Received: by istwok.ods.com id AA19629 (5.65c/IDA-1.3.5); + Fri, 3 Apr 1992 14:13:13 -0600 +From: David Engel +Message-Id: <199204032013.AA19629@istwok.ods.com> +Subject: Re: Standard Proposal for Device Naming +To: abc@banjo.concert.net (Alan B Clegg) +Date: Fri, 3 Apr 92 14:13:12 CST +Cc: linux-standards@banjo.concert.net +In-Reply-To: <199204031746.AA18990@istwok.ods.com>; from "Alan B Clegg" at Apr 3, 92 12:42 pm +X-Mailer: ELM [version 2.3 PL11] + +> How many really use all three? Are there still 720k floppy disks around? +> Why define more than we need? If the need is there, I agree (infact, my +> original draft [internal use only] had Low, Double, and Quad, until I tried +> to find a use for all three... LET ME KNOW! + +There probably aren't too many quads used, but who knows, somebody out +there may actually be using them. As Michael mentioned, we also have to +consider the new 2.88 Meg drives also. + +> I disagree. This leads to confusion (ESPECIALY ON SERIAL DEVICES) of locking +> mechanisms. Is every version of UUCP, kermit and pcomm supposed to know +> that /dev/tty03 == /dev/ttys3 when creating /usr/spool/uucp/LCK..tty03? + +We may just have to agree to disagree on this one. :) + +I see two worthwhile, but conflicting, goals here. The first is to have a +definitive set of specific device names (and numbers) supported by Linux. +The second is to have generic name, coomon across all systems, for the +devices that are actually in use. The problem with the first goal is that +similarly used devices on separate systems have totally different names. +Conversely, the problem with the second is that the devices would have +different numbers. + +What I'm proposing is a compromise. Keep the highly specific device name +you proposed, but allow each user to set up symlinks, probably with the +aid of configuration script, between the generic and specific names. + +I'll admit having generic names for hard disks is probably not very useful +since their use is highly dependent partitioning and file system set up. +However, I fell generic names for other devices such as ttys, floppies and +tapes is very useful. + +Maybe an example might help. Let's say I write "Dave's Nifty Backer-Upper" +for Linux and I want to present the user with a list of destination devices +to make it as user-friendly as possible. With standard, generic names, I +can limit the choices to those valid for his/her system. Without genric +names, I have to include all combinations of floppy, tape (both SCSI and +non-SCSI), most of which aren't valid. Not very user-friendly, IMO. + +As for your example, UUCP, kermit, pcomm, etc. would all be configured to +use tty03. They have no need to know that it is actually ttys3. Ttys3 +would never be referenced directly in normal use. It is only there to +remind you what tty03 really is the next time you reconfigure the hardware +installed in your system. + +-David +-- +David Engel Optical Data Systems, Inc. +david@ods.com 1101 E. Arapaho Road +(214) 234-6400 Richardson, TX 75081 + +From linux-standards-request@banjo.concert.net Sat Apr 4 09:47:17 1992 +Return-Path: +Received: from daimi.aau.dk by banjo.concert.net with SMTP (PP) + id <04650-0@banjo.concert.net>; Sat, 4 Apr 1992 09:46:52 -0500 +Received: from ferrari.daimi.aau.dk by daimi.aau.dk + with SMTP (5.61++/IDA-1.2.8) id AA15569; Sat, 4 Apr 92 16:46:46 +0200 +Received: by ferrari.daimi.aau.dk (5.64/1.34) id AA13200; + Sat, 4 Apr 92 16:46:44 +0200 +Date: Sat, 4 Apr 92 16:46:44 +0200 +From: tthorn@daimi.aau.dk +Message-Id: <9204041446.AA13200@ferrari.daimi.aau.dk> +To: linux-standards@banjo.concert.net +In-Reply-To: ZLSIIAL@cms.mcc.ac.uk's message of Thu, 02 Apr 92 13:17:33 BST <02 Apr 92 13:17:33 BST ZLSIIAL@UK.AC.MCC.CMS> +Subject: Re: flat /dev, fd names + + Date: Thu, 02 Apr 92 13:17:33 BST + From: ZLSIIAL@cms.mcc.ac.uk + Myname: A. V. Le Blanc + + The name of a floppy disk device (at least in 'flat' /dev) would be + fd[drive][density][disksize], where [drive] is 0-3, [density] is + 'd', 'q', or 'h', and [disksize] is '3' or '5'. This seems to me + better than the fd[drive][codeletter] scheme, since I would have + as much difficulty remembering the code letters as I have now + with the hopeless Minix names. + +Yes, everybody agrees that the Minux convention is brain dead, but +I don't like your surgestion. Nobody uses density to destinguish +formats anymore as you could easily have different formats with +the same density. Instead I would prefer devicenames that included +some more meaningful information of the format, such as XXX1440, +XXX1200, or something likewise. + +/Tommy Thorn + + +From linux-standards-request@banjo.concert.net Sat Apr 4 19:18:59 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <05790-0@banjo.concert.net>; Sat, 4 Apr 1992 19:18:28 -0500 +Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP + id <11106-0@sun2.nsfnet-relay.ac.uk>; Sat, 4 Apr 1992 18:02:37 +0100 +Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa12169; + 4 Apr 92 12:05 BST +Date: Sat, 04 Apr 92 11:49:29 +0100 +From: Damiano Bolla +To: linux-standards@banjo.concert.net +Subject: /dev + +I agree with LeBlanc. + +I think that having subdirectoryes in /dev/is possible and desiderable. +If any of your program complains you can always symlink..... + +The all thing is MUCH easier to understand and to maintain. + +BTW: The all point to have this is that the resulting structure +has MORE meaning than the original. + +What I mean is that the all point of this discussion is to end up with +a naming schema that : + +Can be EXPANDED without a change of the rules. +It is EASY to understand what a device is WITHOUT looking at the manual. + +..... + + +Then welcome to + +/dev/fd/scsi... +/dev/fd/wd.. + +/dev/flp/1.4m +/dev/flp/720k +/dev/flp/1.2m + +/dev/mt/wan.... +/dev/mt/col.... + +/dev/mouse/.... + +/dev/midi/sb.. +/dev/midi/... + +/dev/pty/pty1 +/dev/pty/ptym1 +/dev/pty/pty2 +/dev/pty/ptym2 + +Just one thing...... + +we keep the virtual consoles and all serial lines are in /dev +/dev/console +/dev/tty +/dev/tty1 # virtual console +/dev/tty2 # virtual console +....... + +/dev/ttys1 # Serial line +/dev/ttys2 # Serial line +/dev/ttys3 + +I don't think that having a special piece of hardware for more serial +lines wil pose a problem, You will have a different major but you can +allocate the serials where you want. +NOTE: This is possible since ALL serial lines have a common set of +operations available. Ie. the soft DO NOT need to distinguish between +the different brand ( Here software means user programs ) + +Damiano + +From linux-standards-request@banjo.concert.net Sun Apr 5 07:27:32 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <06813-0@banjo.concert.net>; Sun, 5 Apr 1992 07:27:06 -0400 +Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk + via JANET with NIFTP id <1497-0@sun2.nsfnet-relay.ac.uk>; + Sun, 5 Apr 1992 11:55:47 +0100 +Message-id: <05 Apr 92 11:44:47 BST ZLSIIAL@UK.AC.MCC.CMS> +Date: Sun, 05 Apr 92 11:44:47 BST +From: LeBlanc@manchester-computing-centre.ac.uk +MyName: A. V. Le Blanc +To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@banjo.concert.net> +Subject: fd dev + + +Someone has written asking me what is wrong with + /dev/at0 + /dev/xt0 +as names for floppy disks. Well, I am not a beginner either +with DOS or with unix, but the only clue I have to what they +mean is that, for Minix, /dev/at0 is a 1.2mb 5.25in drive. +Does this mean that /dev/xt0 is a 1.4mb 3.5in drive? +These names are meaningless to me, and ought to be eliminated. + +Someone else has written to say, with repect to my suggestion + /dev/fd0h3 + /dev/fd0q5 + /dev/fd1d3 +that we ought to eliminate the final digit. Unfortunately this +means that on some systems /dev/fd0h would be a three inch disk, +on others a 5 inch disk, so that the same name would refer to +different devices. This in turn would lead to software (eg +versions of mtools) that would work on one system but not on +another, and for a reason which would be very hard for us net +friends to track down (at least the first time). If someone +wants to link fd0h to whatever is appropriate for his machine, +let him do so, but software should not be distributed which +refers to system specific devices. + +Someone asked who uses various disk sizes. Around here we have +many 3.5 inch disks at all three densities (double, quad, high) +and many 5.25 inch disks at two densities (double, high). This +is partly because of media prices and partly for historical +reasons, but I don't see any prospect of the odd densities +disappearing for a few years. You may not be in this fix, but +many other educational institutions will probably be. + + -- Owen + LeBlanc@mcc.ac.uk + +From linux-standards-request@banjo.concert.net Sun Apr 5 08:01:19 1992 +Return-Path: +Received: from kruuna.Helsinki.FI by banjo.concert.net with SMTP (PP) + id <06839-0@banjo.concert.net>; Sun, 5 Apr 1992 08:00:55 -0400 +Received: from klaava.Helsinki.FI by kruuna.helsinki.fi with SMTP + id AA17391 (5.65c/IDA-1.4.4 for ); + Sun, 5 Apr 1992 15:00:40 +0300 +Received: by klaava.Helsinki.FI (4.1/SMI-4.1) id AA07225; + Sun, 5 Apr 92 15:00:39 +0300 +Date: Sun, 5 Apr 92 15:00:39 +0300 +From: torvalds@cc.helsinki.fi (Linus Torvalds) +Message-Id: <9204051200.AA07225@klaava.Helsinki.FI> +In-Reply-To: LeBlanc@manchester-computing-centre.ac.uk's message as of Apr 5, 11:44 +X-Mailer: Mail User's Shell (7.1.1 5/02/90) +To: linux-standards +Subject: Re: fd dev + +Ok, I didn't want to get into this very much, but I'd like to say my 2c +in the discussion (I'll conform to whatever the group decides on, but I +hope I'll like it too...) + +- I decidedly dislike the non-flat proposals: I know it looks nice when +you do an 'ls' on the device directory, but it does break a lot of +programs (rootdev, tty etc all goe through the dev-directory to find out +the correct names). And these programs aren't just small programs +written for linux: the GNU library function ttyname() depends on the +tty's being in a flat directory etc.. + +- I'd like this kind of floppy-structure (I think it's been proposed by +others, but repeating it won't hurt): + + /dev/fdndxxxx + +where n is the floppy drive number, d is the density/size of the /drive/ +and xxxx is the size of the disk. The encoding of 'd' might be a +problem: you have to distinguish 5.25" and 3.5" high density drives +(both can read 360/720kB disks), but I think the name could be pretty +easy to remember. Of course, everybody would link their own names +depending on what kind of drive they have, but this could be the general +"standard" names. + +This could result in names like ('d' is uppercase means 3.5" - just a +thought): + + /dev/fd0H1440 (1.44MB disk in 3.5" drive) + /dev/fd0d360 (360kB disk in double-denstiry 5.25" drive) + /dev/fd0h360 (360kB disk in high-denstiry 5.25" drive) + /dev/fd0H360 (360kB disk in 3.5" drive) + +etc. Pretty easy to remember, and it does give the user a picture of +what kind of drive it's all about, once he knows the general rules. + +- I disagree slightly with the /dev/wdxy structure, where 'x' is a +harddisk number, and 'y' is a alphabetic character for the partition for +two reasons: + + - it seems 'y' = c means the whole disk under BSD. Very confusing + if it just means partition nr 3 under linux. + - although unlikely, there can be more than 27 partitions/disk. + +I'd rather see the current naming remain, with the change that 'hd' is +just renamed as 'wd'. Nobody has had any major complaints with the +current naming, I think, except for the possibility of confusion with +SCSI etc drives if we just call them 'hd'. I think it's logical to call +harddisk 0 /dev/wda, and it's partitions /dev/wdaXX.. (with a possible +'r' before the name for raw devices, although linux doesn't support them +as separate devices right now...) + + Linus + +From linux-standards-request@banjo.concert.net Sun Apr 5 10:56:44 1992 +Return-Path: +Received: from daimi.aau.dk by banjo.concert.net with SMTP (PP) + id <06923-0@banjo.concert.net>; Sun, 5 Apr 1992 10:56:17 -0400 +Received: by daimi.aau.dk (5.61++/IDA-1.2.8) id AA08494; + Sun, 5 Apr 92 16:56:03 +0200 +From: Tommy Thorn +Message-Id: <9204051456.AA08494@daimi.aau.dk> +Subject: Re: fd dev +To: torvalds@cc.helsinki.fi (Linus Torvalds) +Date: Sun, 5 Apr 92 16:56:02 BST +Cc: linux-standards@banjo.concert.net +In-Reply-To: <9204051200.AA07225@klaava.Helsinki.FI>; from "Linus Torvalds" at Apr 5, 92 3:00 pm +X-Mailer: ELM [version 2.3 PL11] + +YES!! Linus suggestion hits the nailhead. I support it 100%. + +/Tommy Thorn + +From linux-standards-request@banjo.concert.net Sun Apr 5 13:46:39 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <07065-0@banjo.concert.net>; Sun, 5 Apr 1992 13:46:07 -0400 +Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk + via JANET with NIFTP id <4306-0@sun2.nsfnet-relay.ac.uk>; + Sun, 5 Apr 1992 14:41:55 +0100 +Message-id: <05 Apr 92 12:06:17 BST ZLSIIAL@UK.AC.MCC.CMS> +Date: Sun, 05 Apr 92 12:06:17 BST +From: LeBlanc@manchester-computing-centre.ac.uk +MyName: A. V. Le Blanc +To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@banjo.concert.net> +Subject: proposed names + + +I read with interest the proposal for device names. I am unhappy +about two of them: + + /dev/{r}wd[C][N][P] + +where C is [a-z], N is [0-9], and P is [a-z]. It would be better to +have C as [0-9], N as [a-z], and P as [1-xx]. Otherwise we must +change or violate the standard when dealing with more than 26 +partitions. The code in the kernel now deals with up to 60 partitions. + + /dev/{r}fd[N][S][D] + +where N is [0-3], S is [358], and P is [hqld] It would be better to have +P before S to preserve letter/digit alternation. + + -- Owen + LeBlanc@mcc.ac.uk + +From linux-standards-request@banjo.concert.net Sun Apr 5 13:47:00 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <07065-1@banjo.concert.net>; Sun, 5 Apr 1992 13:46:13 -0400 +Received: from thor.cardiff.ac.uk by sun2.nsfnet-relay.ac.uk via JANET + with NIFTP id <7806-0@sun2.nsfnet-relay.ac.uk>; + Sun, 5 Apr 1992 16:52:19 +0100 +From: Paul Richards +Message-Id: <24759.9204051553@thor.cf.ac.uk> +Subject: floppy names +To: linux-standards@banjo.concert.net (linux-standards) +Date: Sun, 5 Apr 92 16:53:40 WET DST +X-Mailer: ELM [version 2.3 PL11] + + +I've obviously missed something fundamental but I don't see why we need +device specific names. Why can't we just have /dev/fpx where x is a +number or letter or whatever. There's only one device driver for floppy +disks and I can't see why this would be likely to change. Surely we +should differentiate between drivers and not different types of +underlying hardware. + +If there are large numbers of different names for floppies then writing +portable software for them is going to be a nightmare since all the +different names for each possible drive will have to be catered for. I +can't see why this is necessary. No software that I know of needs to +know the capacity of the drive. Even if there is and I've just thought +of a few cases, then surely the driver should supply this information. + +As an example, say I change my old 5.25 disk for a nice new 2.88M 3.5. +If we use the hardware based scheme then I'll have to modify all my +software to use the new device name. Ok I hear you say, make a link. +Well if we all link these hardware based names to something like /dev/fp +then why not just make it the standard in the first place. + +If we use /dev/fp and I change my drive nothing has to change except the +major/minor device number. All software still accesses /dev/fp and the +driver takes care of the underlying hardware. + +To sum up, I think device names should be based on whether there are +different drivers and not on different hardware. + +-- + Paul Richards at Cardiff university, UK. + + spedpr@uk.ac.cf.thor Internet: spedpr%thor.cf.ac.uk@nsfnet-relay.ac.uk + UUCP: spedpr@thor.cf.UUCP or ...!uunet!mcsun!ukc!cf!thor!spedpr ++++ + +From linux-standards-request@banjo.concert.net Sun Apr 5 16:29:36 1992 +Return-Path: +Received: from vxicp1.ictp.trieste.it by banjo.concert.net with SMTP (PP) + id <07179-0@banjo.concert.net>; Sun, 5 Apr 1992 16:29:08 -0400 +Return-path: pietrak@itsictp.bitnet +Received: from dec3100b.ictp.trieste.it by ITSICTP.BITNET; Sun, 5 Apr 92 14:12 N +Received: by dec3100b.ictp.trieste.it (5.57/Ultrix3.0-C) id AA27433; + Sun, 5 Apr 92 14:09:24 +0100 +Date: Sun, 5 Apr 92 14:09:24 +0100 +From: Pietrak Rafal +Subject: Re: fd dev +To: linux-standards@banjo.concert.net, torvalds@cc.helsinki.fi +Full-Name: Pietrak Rafal +Message-Id: <9204051309.AA27433@dec3100b.ictp.trieste.it> + +Tough, I'd prefere having not more then a screenfull in every dir, if +hierarchical /dev breaks important and none-trivial programs, well,... +so let there be flat /dev directory. (BTW, I liked UNIX a lot -- and +Linux in particular -- but here both lost a bit of my hart). + +As for the block devices naming, I would prefere naming scheme like: +/dev/[A][N][A][N]..., where S is [a-z] (may be [A-Z], too) strings, and +N is [0-9] strings, that is numbers. + + + - Rafal + +From linux-standards-request@banjo.concert.net Sun Apr 5 21:25:46 1992 +Return-Path: +Received: from sage.cc.purdue.edu by banjo.concert.net with SMTP (PP) + id <07558-0@banjo.concert.net>; Sun, 5 Apr 1992 21:25:19 -0400 +Received: by sage.cc.purdue.edu (5.61/Purdue_CC) id AA11790; + Sun, 5 Apr 92 20:23:24 -0500 +From: asg@sage.cc.purdue.edu (Bruce Varney) +Message-Id: <9204060123.AA11790@sage.cc.purdue.edu> +Subject: Re: fd dev +To: LeBlanc@manchester-computing-centre.ac.uk +Date: Sun, 5 Apr 92 20:23:23 EST +Cc: linux-standards@banjo.concert.net +In-Reply-To: <05 Apr 92 11:44:47 BST ZLSIIAL@UK.AC.MCC.CMS>; from "LeBlanc@manchester-computing-centre.ac.uk" at Apr 5, 92 11:44 am +Needs: Your attention +Organization: Fraternal Order of Red-haired Milkmaids + +In the unforgettable words of LeBlanc@manchester-computing-centre.ac.uk: +-> +-> +->Someone has written asking me what is wrong with +-> /dev/at0 +-> /dev/xt0 +->These names are meaningless to me, and ought to be eliminated. + + YES!! + +-> +->Someone else has written to say, with repect to my suggestion +-> /dev/fd0h3 +-> /dev/fd0q5 +-> /dev/fd1d3 +->that we ought to eliminate the final digit. Unfortunately this +->means that on some systems /dev/fd0h would be a three inch disk, +->on others a 5 inch disk, so that the same name would refer to +->different devices. This in turn would lead to software (eg +->versions of mtools) that would work on one system but not on +->another, and for a reason which would be very hard for us net +->friends to track down (at least the first time). If someone +->wants to link fd0h to whatever is appropriate for his machine, +->let him do so, but software should not be distributed which +->refers to system specific devices. + + Well, I don't see how your last statement is in agreement with +everyting else. Software should refer to /dev/fd0, and /dev/fd1. The +kernel should have the job of using the appropriate driver. You are +right. Software should NOT refer to system specific devices. /dev/fd0h3 +IS a system specific device. /dev/fd0 is a "generic" device. The name +is that of the first floppy drive. The kernel will allocate the +appropriate driver. + + Bruce + +From linux-standards-request@banjo.concert.net Sun Apr 5 21:33:08 1992 +Return-Path: +Received: from sage.cc.purdue.edu by banjo.concert.net with SMTP (PP) + id <07572-0@banjo.concert.net>; Sun, 5 Apr 1992 21:32:41 -0400 +Received: by sage.cc.purdue.edu (5.61/Purdue_CC) id AA12774; + Sun, 5 Apr 92 20:30:05 -0500 +From: asg@sage.cc.purdue.edu (Bruce Varney) +Message-Id: <9204060130.AA12774@sage.cc.purdue.edu> +Subject: Re: floppy names +To: spedpr@thor.cardiff.ac.uk (Paul Richards) +Date: Sun, 5 Apr 92 20:30:04 EST +Cc: linux-standards@banjo.concert.net +In-Reply-To: <24759.9204051553@thor.cf.ac.uk>; from "Paul Richards" at Apr 5, 92 4:53 pm +Needs: Your attention +Organization: Fraternal Order of Red-haired Milkmaids + +In the unforgettable words of Paul Richards: +-> +-> +->device specific names. Why can't we just have /dev/fpx where x is a +->number or letter or whatever. There's only one device driver for floppy + + YES!!! + +->If we use /dev/fp and I change my drive nothing has to change except the +->major/minor device number. All software still accesses /dev/fp and the +->driver takes care of the underlying hardware. + YES!!! + + THANK YOU + At least I know someone out there agrees with me. + Bruce + +From linux-standards-request@banjo.concert.net Sun Apr 5 21:57:32 1992 +Return-Path: +Received: from kinglear.cs.colorado.edu by banjo.concert.net with SMTP (PP) + id <07601-0@banjo.concert.net>; Sun, 5 Apr 1992 21:57:06 -0400 +Received: from localhost by kinglear.cs.Colorado.EDU with SMTP + id AA26775 (5.65c/IDA-1.4.4 for linux-standards@banjo.concert.net); + Sun, 5 Apr 1992 19:56:55 -0600 +Message-Id: <199204060156.AA26775@kinglear.cs.Colorado.EDU> +To: asg@sage.cc.purdue.edu (Bruce Varney) +Cc: linux-standards@banjo.concert.net +Subject: Re: floppy names +In-Reply-To: Your message of Sun, 05 Apr 92 20:30:04 -0500. <9204060130.AA12774@sage.cc.purdue.edu> +Date: Sun, 05 Apr 92 19:56:54 MST +From: drew@kinglear.cs.Colorado.EDU + + +-------- + + In the unforgettable words of Paul Richards: + -> + -> + ->device specific names. Why can't we just have /dev/fpx where x is a + ->number or letter or whatever. There's only one device driver for floppy + + YES!!! + + ->If we use /dev/fp and I change my drive nothing has to change except the + ->major/minor device number. All software still accesses /dev/fp and the + ->driver takes care of the underlying hardware. + YES!!! + + THANK YOU + At least I know someone out there agrees with me. + Bruce + +-------- +The problem with this approach is that high density and extra density +floppies can support two or more denisties per drive. So that these +are accesable to the user, either + +1. The kernel must check for disk type. +2. The user must be able to specify media density, ie with a suffix. + +Unless you're willing to volunteer for floppy disk driver work, +or some one else is, the later is what we are stuck with. + +AIX uses the later approach, with +/dev/fd[n] the default, high density media, and +/dev/fd[n] available for low density media. + + + +From linux-standards-request@banjo.concert.net Sun Apr 5 22:19:51 1992 +Return-Path: +Received: from sage.cc.purdue.edu by banjo.concert.net with SMTP (PP) + id <07625-0@banjo.concert.net>; Sun, 5 Apr 1992 22:19:26 -0400 +Received: by sage.cc.purdue.edu (5.61/Purdue_CC) id AA22617; + Sun, 5 Apr 92 21:19:18 -0500 +From: asg@sage.cc.purdue.edu (Bruce Varney) +Message-Id: <9204060219.AA22617@sage.cc.purdue.edu> +Subject: Re: floppy names +To: drew@kinglear.cs.Colorado.EDU +Date: Sun, 5 Apr 92 21:19:17 EST +Cc: linux-standards@banjo.concert.net +In-Reply-To: <199204060156.AA26775@kinglear.cs.Colorado.EDU>; from "drew@kinglear.cs.Colorado.EDU" at Apr 5, 92 7:56 pm +Needs: Your attention +Organization: Fraternal Order of Red-haired Milkmaids + +->The problem with this approach is that high density and extra density +->floppies can support two or more denisties per drive. So that these +->are accesable to the user, either +-> +->1. The kernel must check for disk type. +->2. The user must be able to specify media density, ie with a suffix. +-> +->Unless you're willing to volunteer for floppy disk driver work, +->or some one else is, the later is what we are stuck with. +-> + If I had a machine to do it on, I would gladly. Anyone wanna +make a donation? ;-) + + Dos doesn't require that you specify which density your disk +is. So it obviously isn't impossible for the OS to determine it. I am +not completely familiar with how floppies are layed out, but isn't there +something that is peculiar to each density? Even Minix has a device +(/dev/fd0 or something) that will figure out for you what density +disk is in the drive. + + Bruce + +From linux-standards-request@banjo.concert.net Mon Apr 6 04:58:04 1992 +Return-Path: +Received: from daimi.aau.dk by banjo.concert.net with SMTP (PP) + id <08085-0@banjo.concert.net>; Mon, 6 Apr 1992 04:31:17 -0400 +Received: from jaguar.daimi.aau.dk by daimi.aau.dk with SMTP (5.61++/IDA-1.2.8) + id AA28639; Mon, 6 Apr 92 10:31:11 +0200 +Received: by jaguar.daimi.aau.dk (5.64/1.34) id AA12440; + Mon, 6 Apr 92 10:31:09 +0200 +From: poe@daimi.aau.dk +Message-Id: <9204060831.AA12440@jaguar.daimi.aau.dk> +Subject: Re: Standard Proposal for Device Naming +To: abc@banjo.concert.net (Alan B Clegg) +Date: Mon, 6 Apr 92 10:31:09 MET DST +Cc: linux-standards@banjo.concert.net +In-Reply-To: <9204031756.AA22905@daimi.aau.dk>; from "Alan B Clegg" at Apr 3, 92 12:42 pm +Organization: DAIMI, Computer Science Department of Aarhus University +Phone: 86 20 27 11 - 5034 +X-Mailer: ELM [version 2.3 PL11] + +> > I think we should stick with the standard density names, ie. d=double, +> > q=quad and h=high. +> +> How many really use all three? Are there still 720k floppy disks around? +> Why define more than we need? If the need is there, I agree (infact, my +> original draft [internal use only] had Low, Double, and Quad, until I tried +> to find a use for all three... LET ME KNOW! + +I for one would not want the 720k floppies to be discarded. My Amiga can read/ +write these, and not the 1.44MB ones. + +And I do have some stuff on the Amiga that I might want to use under Linux. + + - Peter. + +From linux-standards-request@banjo.concert.net Mon Apr 6 09:17:37 1992 +Return-Path: +Received: from banjo.concert.net by banjo.concert.net + id <09110-0@banjo.concert.net>; Mon, 6 Apr 1992 09:16:46 -0400 +Subject: Proposed Naming Changes (from + LeBlanc@manchester-computing-centre.ac.uk) +To: linux-standards@banjo.concert.net +Date: Mon, 6 Apr 92 9:16:41 EDT +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@banjo.concert.net + +In previous mail, LeBlanc@manchester-computing-centre.ac.uk said something like: + +> /dev/{r}wd[C][N][P] +> +> where C is [a-z], N is [0-9], and P is [a-z]. It would be better to +> have C as [0-9], N as [a-z], and P as [1-xx]. Otherwise we must +> change or violate the standard when dealing with more than 26 +> partitions. The code in the kernel now deals with up to 60 partitions. + +This is good, and I agree, but it causes ugly side-effects in the sd code. +SCSI devices are NUMBERED, so unless we have two different naming schemes +for scsi and wd type disks, we have a conflict. I agree that support for +60 partitions is in the kernel, but if we expanded the range of P from [a-z] +to [a-zA-Z], we double up to 52 and have support for devices up to 1664Meg +even with the current 32Meg partition maximum size (I assume that will go +away shortly). + +I believe that Linus has good ideas on the Floppy drive naming, and I am +re-writing the document do reflect that, but I still think that we should +allow support (even if not currently available) for multiple disk controllers +of any given type. I am about to put a ST-01 into my machine that already +has an Adaptec 1542 board in it to try out some things in the SCSI code and +would hate to have to make up my own naming scheme.. 8-) + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux-standards-request@banjo.concert.net Mon Apr 6 10:09:03 1992 +Return-Path: +Received: from banjo.concert.net by banjo.concert.net + id <09376-0@banjo.concert.net>; Mon, 6 Apr 1992 10:08:31 -0400 +Subject: Standard Release (ABC Release of Linux .95a) +To: linux-standards@banjo.concert.net +Date: Mon, 6 Apr 92 10:08:27 EDT +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@banjo.concert.net + +With the advent of GCC 2.1 and shared libraries, here is a question: + +Every program in /bin *WILL* be linked static. I have already had to rebuild +from one "accidental" removal of the shared libraries with shared executables +in /bin (rm, cp, etc etc). + +BUT: Should there be a dynamic version of every program that currently lives +in /bin in /usr/bin? If so, and users have /usr/bin in their path before +/bin, we allow the use of shared libraries for most programs, and we don't +blow off a *LOT* of disk space... + +Just an idea.... + + from the tormented mind of... + + -abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux-standards-request@banjo.concert.net Mon Apr 6 14:36:08 1992 +Return-Path: +Received: from twok.ods.com by banjo.concert.net with SMTP (PP) + id <10960-0@banjo.concert.net>; Mon, 6 Apr 1992 14:35:29 -0400 +Received: by istwok.ods.com id AA22625 (5.65c/IDA-1.3.5); + Mon, 6 Apr 1992 13:39:00 -0500 +From: David Engel +Message-Id: <199204061839.AA22625@istwok.ods.com> +Subject: Re: Standard Release (ABC Release of Linux .95a) +To: abc@banjo.concert.net (Alan B Clegg) +Date: Mon, 6 Apr 92 13:38:59 CDT +Cc: linux-standards@banjo.concert.net +In-Reply-To: <199204061413.AA19542@istwok.ods.com>; from "Alan B Clegg" at Apr 6, 92 10:08 am +X-Mailer: ELM [version 2.3 PL11] + +> With the advent of GCC 2.1 and shared libraries, here is a question: +> +> Every program in /bin *WILL* be linked static. I have already had to rebuild +> from one "accidental" removal of the shared libraries with shared executables +> in /bin (rm, cp, etc etc). + +Well, I plan on putting shared binaries in /bin, but I also plan on putting +together my own "emergency" root disk with a backup copy of the shared library +and essential binaries in case I screw up. + +I don't know the nature of your accidental removal but here a couple things +I've done to hopefully avoid doing so myself. First, DO NOT put a symlink +in /lib to the shared library in /usr/shared/lib. Copy it to /lib instead. +That way you can safely remove /usr/shared when the next update comes around. +Second, change the mode on your shared libs to 444. Unless you do an rm -f, +the prompt for comfirmation should make you think twice about deleting it. + +> BUT: Should there be a dynamic version of every program that currently lives +> in /bin in /usr/bin? If so, and users have /usr/bin in their path before +> /bin, we allow the use of shared libraries for most programs, and we don't +> blow off a *LOT* of disk space... + +Huh? Wouldn't keeping static versions in /bin and shared versions in /usr/bin +wast *more* disk space than just static versions in /bin (maybe with symlinks +in /usr/bin)? + +-David +-- +David Engel Optical Data Systems, Inc. +david@ods.com 1101 E. Arapaho Road +(214) 234-6400 Richardson, TX 75081 + +From linux-standards-request@banjo.concert.net Mon Apr 6 15:39:23 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <11320-1@banjo.concert.net>; Mon, 6 Apr 1992 15:38:29 -0400 +Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk + via JANET with NIFTP id <10015-0@sun2.nsfnet-relay.ac.uk>; + Mon, 6 Apr 1992 14:43:24 +0100 +Message-id: <06 Apr 92 11:44:17 BST ZLSIIAL@UK.AC.MCC.CMS> +Date: Mon, 06 Apr 92 11:44:17 BST +From: LeBlanc@manchester-computing-centre.ac.uk +MyName: A. V. Le Blanc +To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@banjo.concert.net> +Subject: device names + + +I very much like Linus's suggestions, but I have one reservation. +The use of upper case/lower case to distinguish between 3.5/5.25 +inch drives leaves us with no way of incorporating other sizes +into the pattern unless their disk geometries match one of these +two. (In any case, I have already changed my /devs to +fd0H1440 and fd1h1200 and so forth.) + +Standardising device names is a pain, since there is not a great +deal of uniformity among existing systems. It may be tempting +to adopt names or name formats from elsewhere, which DOES have +the advantage of not adding to the muddle, but we must be +cautious about carrying over conventions which may hinder Linux's +usefulness. I am no Unix beginner, but if it helps beginners, +I'm for it. I say this because many will be (and already are) +using Linux who have little or no Unix experience, and we are +already seeing dozens of questions from them on comp/alt.os.linux +and elsewhere. + +I was listening with an open mind (I hope) to the suggestion +that we abandon device-specific names in favour of generic names, +e.g., fd0 for all floppies on the first drive. There is a lot +to be said for this kind of simplicity, which could, for example, +be created by an installation/configuration script, and I haven't +completely rejected it. But among the problems I see with it, +one stands out in particular. It is in fact necessary to have +different device names for differently formatted floppies in the +same drive. This is partially because there is no generic way +of finding out the disk's parameters. Moreover, I and most of +my users have many disks of many densities, so I can't see this +problem going away. + + -- Owen + LeBlanc@mcc.ac.uk + +From linux-standards-request@banjo.concert.net Mon Apr 6 15:39:48 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <11320-2@banjo.concert.net>; Mon, 6 Apr 1992 15:38:38 -0400 +Received: from cms.manchester-computing-centre.ac.uk by sun2.nsfnet-relay.ac.uk + via JANET with NIFTP id <10600-0@sun2.nsfnet-relay.ac.uk>; + Mon, 6 Apr 1992 15:08:39 +0100 +Message-id: <06 Apr 92 11:44:17 BST ZLSIIAL@UK.AC.MCC.CMS> +Date: Mon, 06 Apr 92 11:44:17 BST +From: LeBlanc@manchester-computing-centre.ac.uk +MyName: A. V. Le Blanc +To: linux-standards <@nsfnet-relay.ac.uk:linux-standards@banjo.concert.net> +Subject: device names + + +I very much like Linus's suggestions, but I have one reservation. +The use of upper case/lower case to distinguish between 3.5/5.25 +inch drives leaves us with no way of incorporating other sizes +into the pattern unless their disk geometries match one of these +two. (In any case, I have already changed my /devs to +fd0H1440 and fd1h1200 and so forth.) + +Standardising device names is a pain, since there is not a great +deal of uniformity among existing systems. It may be tempting +to adopt names or name formats from elsewhere, which DOES have +the advantage of not adding to the muddle, but we must be +cautious about carrying over conventions which may hinder Linux's +usefulness. I am no Unix beginner, but if it helps beginners, +I'm for it. I say this because many will be (and already are) +using Linux who have little or no Unix experience, and we are +already seeing dozens of questions from them on comp/alt.os.linux +and elsewhere. + +I was listening with an open mind (I hope) to the suggestion +that we abandon device-specific names in favour of generic names, +e.g., fd0 for all floppies on the first drive. There is a lot +to be said for this kind of simplicity, which could, for example, +be created by an installation/configuration script, and I haven't +completely rejected it. But among the problems I see with it, +one stands out in particular. It is in fact necessary to have +different device names for differently formatted floppies in the +same drive. This is partially because there is no generic way +of finding out the disk's parameters. Moreover, I and most of +my users have many disks of many densities, so I can't see this +problem going away. + + -- Owen + LeBlanc@mcc.ac.uk + +From linux-standards-request@banjo.concert.net Tue Apr 7 04:12:37 1992 +Return-Path: +Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <13608-4@banjo.concert.net>; Tue, 7 Apr 1992 03:44:06 -0400 +Received: from thor.cardiff.ac.uk by sun2.nsfnet-relay.ac.uk via JANET + with NIFTP id <24859-0@sun2.nsfnet-relay.ac.uk>; + Tue, 7 Apr 1992 03:24:37 +0100 +From: Paul Richards +Message-Id: <6203.9204070226@thor.cf.ac.uk> +Subject: Re: device names +To: linux-standards@banjo.concert.net (linux-standards) +Date: Tue, 7 Apr 92 3:26:00 WET DST +X-Mailer: ELM [version 2.3 PL11] + +In reply to LeBlanc@uk.ac.manchester-computing-centre who said +> completely rejected it. But among the problems I see with it, +> one stands out in particular. It is in fact necessary to have +> different device names for differently formatted floppies in the +> same drive. This is partially because there is no generic way +> of finding out the disk's parameters. Moreover, I and most of +> my users have many disks of many densities, so I can't see this +> problem going away. + +It obviously isn't necessary to have different device names since DOS +deals with this perfectly well and if DOS can do it we can certainly get +Linux to do it. Of course, someone will have to enlighten us as to how +DOS does it? + +Since this is an option when the floppy is formatted is the information +stored during the format in some way. It seems to me that this is a DOS +problem in any case. What you're saying is you have lots of DOS floppies +lying around of different densities. Are we going to base the device +names on this necessity? Are we really going to continue writing DOS +format floppies from within Linux? For that matter do we need floppies +apart from backing up? (Sorry I'm getting a bit ridiculous but these +points did cross my mind). + +As an actual proposal. We can keep simple names by makinf the driver try +the most common density first. If an error occurs then try another one +and so on. If none of them work then report an error. Not ideal but it +does show its possible. Someone must know what DOS does? + + +-- + Paul Richards at Cardiff university, UK. + + spedpr@uk.ac.cf.thor Internet: spedpr%thor.cf.ac.uk@nsfnet-relay.ac.uk + UUCP: spedpr@thor.cf.UUCP or ...!uunet!mcsun!ukc!cf!thor!spedpr ++++ + +From linux-standards-request@banjo.concert.net Tue Apr 7 06:33:02 1992 +Return-Path: +Received: from bernina.ethz.ch by banjo.concert.net with SMTP (PP) + id <14052-0@banjo.concert.net>; Tue, 7 Apr 1992 06:32:39 -0400 +Received: from nessie by bernina.ethz.ch with SMTP inbound + id <9921-0@bernina.ethz.ch>; Tue, 7 Apr 1992 12:32:18 +0200 +Received: by nessie.cs.id.ethz.ch; Tue, 7 Apr 92 12:32:14 +0200 +Message-Id: <9204071032.AA21232@nessie.cs.id.ethz.ch> +From: almesber@nessie.cs.id.ethz.ch (Werner Almesberger) +Date: Tue, 7 Apr 1992 12:32:13 +0000 +X-Mailer: Mail User's Shell (7.2.3 5/22/91) +To: linux-standards@banjo.concert.net +Subject: Re: device names + +Paul Richards writes: +> It obviously isn't necessary to have different device names since DOS +> deals with this perfectly well and if DOS can do it we can certainly get +> Linux to do it. Of course, someone will have to enlighten us as to how +> DOS does it? + +Step 1: DOS finds out what density it has to use to read the first track. +Linux could do that too. Step 2: DOS reads some sectors that describe the +remaining disk parameters (cylinders, sectors/track, single/double sided, +etc.). Because Linux does not keep such magic sectors on the disk, it has +to have other ways to determine those parameters. + +> Are we really going to continue writing DOS format floppies from +> within Linux? For that matter do we need floppies apart from backing up? + +It doesn't matter what we actually do with the disks. The large number of +different physical formats will always be problem. There are at least four +common physically different types of floppies (360k, 1.2M, 720k and 1.44M) +and there are much more confusing formats (i.e. single-sided ones) that DOS' +FORMAT will happily create. + +> As an actual proposal. We can keep simple names by makinf the driver try +> the most common density first. If an error occurs then try another one +> and so on. If none of them work then report an error. Not ideal but it +> does show its possible. Someone must know what DOS does? + +That sounds good. We'd have to have different devices for 3.5" and 5.25" +disks, the 5.25"/720k format would not be supported and there might be +problems when new formats become widely used. There might be an ioctl to +tell the driver about other, 'non-standard' formats. How about this: + + /dev/fd0.5 /dev/fd1.5 # 5.25", drive A: and B: + /dev/fd0.3 /dev/fd1.3 # 3.5", drive A: and B: + +For most practical purposes, this would avoid the need to make non- +obvious decisions about the floppy format. + +- Werner + +-- + _________________________________________________________________________ + / Werner Almesberger, ETH Zuerich, CH almesber@nessie.cs.id.ethz.ch / + / IFW A44 Tel. +41 1 254 7213 almesberger@rzvax.ethz.ch / +/_BITNET:_ALMESBER@CZHETH5A__HEPNET/CHADNET:_[20579::]57414::ALMESBERGER_/ + + +From linux-standards-request@banjo.concert.net Tue Apr 7 10:56:54 1992 +Return-Path: +Received: from sage.cc.purdue.edu by banjo.concert.net with SMTP (PP) + id <14697-0@banjo.concert.net>; Tue, 7 Apr 1992 10:56:25 -0400 +Received: by sage.cc.purdue.edu (5.61/Purdue_CC) id AA27722; + Tue, 7 Apr 92 09:56:08 -0500 +From: asg@sage.cc.purdue.edu (Bruce Varney) +Message-Id: <9204071456.AA27722@sage.cc.purdue.edu> +Subject: Re: device names +To: almesber@nessie.cs.id.ethz.ch (Werner Almesberger) +Date: Tue, 7 Apr 92 9:56:07 EST +Cc: linux-standards@banjo.concert.net +In-Reply-To: <9204071032.AA21232@nessie.cs.id.ethz.ch>; from "Werner Almesberger" at Apr 7, 92 12:32 pm +Needs: Your attention +Organization: Fraternal Order of Red-haired Milkmaids + +In the unforgettable words of Werner Almesberger: +-> +->That sounds good. We'd have to have different devices for 3.5" and 5.25" +->disks, the 5.25"/720k format would not be supported and there might be +->problems when new formats become widely used. There might be an ioctl to +->tell the driver about other, 'non-standard' formats. How about this: +-> +-> /dev/fd0.5 /dev/fd1.5 # 5.25", drive A: and B: +-> /dev/fd0.3 /dev/fd1.3 # 3.5", drive A: and B: +-> + + This exactly what I think we should avoid! +Why do you need /dev/fd0.5 and /dev/fd0.3?? Do you have a 3.5" drive and +a 5.25" drive that are both assigned as drive 0???? Of course not! The +driver will know what to do with the drive based on the major an minor +numbers. The driver DOESN'T CARE WHAT THE NAME IS!! If I had a device named +/dev/gribble, and assign it the appropriate major and minor to be a +high deensity 3.5" drive in slot 0, it should work just fine. + + Bruce + +From linux-standards-request@banjo.concert.net Tue Apr 7 11:15:42 1992 +Return-Path: +Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP) + id <14882-0@banjo.concert.net>; Tue, 7 Apr 1992 11:15:00 -0400 +Received: by sumax.seattleu.edu id AA06113 (5.65a/IDA-1.4.2 + for linux-standards@banjo.concert.net); Tue, 7 Apr 92 08:10:54 -0700 +Date: Tue, 7 Apr 92 08:10:54 -0700 +From: Chuck Boyer +Message-Id: <9204071510.AA06113@sumax.seattleu.edu> +To: almesber@nessie.cs.id.ethz.ch, asg@sage.cc.purdue.edu +Subject: Re: device names +Cc: linux-standards@banjo.concert.net + +At present we need to heat up this discussion, so that it can end +somewhere.... or just adopt a concensus standard (now) and let +everybody adjust. Whatever is best for programmers... let's do +it. I will adjust beginner's guide, etc./other things as necessary. +boyer@sumax.seattleu.edu +chuck + +From linux-standards-request@banjo.concert.net Tue Apr 7 12:26:40 1992 +Return-Path: +Received: from bernina.ethz.ch by banjo.concert.net with SMTP (PP) + id <15086-0@banjo.concert.net>; Tue, 7 Apr 1992 12:26:13 -0400 +Received: from nessie by bernina.ethz.ch with SMTP inbound + id <17718-0@bernina.ethz.ch>; Tue, 7 Apr 1992 18:26:05 +0200 +Received: by nessie.cs.id.ethz.ch; Tue, 7 Apr 92 18:25:59 +0200 +Message-Id: <9204071625.AA08652@nessie.cs.id.ethz.ch> +From: almesber@nessie.cs.id.ethz.ch (Werner Almesberger) +Date: Tue, 7 Apr 1992 18:25:58 +0000 +In-Reply-To: asg@sage.cc.purdue.edu (Bruce Varney) "Re: device names" (Apr 7, 9:56) +X-Mailer: Mail User's Shell (7.2.3 5/22/91) +To: asg@sage.cc.purdue.edu (Bruce Varney) +Subject: Re: device names +Cc: linux-standards@banjo.concert.net + +Bruce Varney writes: +> Why do you need /dev/fd0.5 and /dev/fd0.3?? Do you have a 3.5" drive and +> a 5.25" drive that are both assigned as drive 0???? Of course not! + +Well, I don't like to have more than one name for the same physical +device (or part of one) myself. But there seems to be no way around +it :-( + +> The driver will know what to do with the drive based on the major an minor +> numbers. The driver DOESN'T CARE WHAT THE NAME IS!! + +Right, the minor numbers should be different. This is what the driver IMHO +should do: + + /dev/fn?.5: - try to set the drive up to use high density disks + - access the disk + - if this works, we have a 1.2 MB disk + - if it doesn't, switch to low density + - try accessing the disk + - if it works, it's an old 360k disk + - if it doesn't, repeat the whole procedure a few + times, then return an error + + /dev/fn?.3: the same procedure, but the values are 1.44 MB and + 720k + +An auto-detection mechanism for all four formats would be more compli- +cated, slower and unreliable, especially in the presence of media +errors. + +Of course it's one of the flaws of this proposal, that it requires +changes to the floppy driver. + +- Werner + +-- + _________________________________________________________________________ + / Werner Almesberger, ETH Zuerich, CH almesber@nessie.cs.id.ethz.ch / + / IFW A44 Tel. +41 1 254 7213 almesberger@rzvax.ethz.ch / +/_BITNET:_ALMESBER@CZHETH5A__HEPNET/CHADNET:_[20579::]57414::ALMESBERGER_/ + + +From linux-standards-request@banjo.concert.net Tue Apr 7 16:39:44 1992 +Return-Path: +Received: from vipunen.hut.fi by banjo.concert.net with SMTP (PP) + id <15898-0@banjo.concert.net>; Tue, 7 Apr 1992 16:39:13 -0400 +Received: by vipunen.hut.fi (5.65c/7.0/S-TeKoLa) id AA89584; + Tue, 7 Apr 1992 20:38:41 GMT +Date: Tue, 7 Apr 1992 20:38:41 GMT +From: Pauli R{m| +Message-Id: <199204072038.AA89584@vipunen.hut.fi> +To: almesber@nessie.cs.id.ethz.ch, asg@sage.cc.purdue.edu +Subject: Re: device names +Cc: linux-standards@banjo.concert.net + +Why can't the diskette drive type just be read from the cmos at bootup +like the info about hard disks? That way there should be no need to +use multiple device names (and minor numbers) for different types of +drives. The auto-detection would also be much easier, because the kernel +had to check for at most 2 densities. The density could of course be +checked by trying to read sector 10 from the first track (at least in +the case of 360k/1.2M and 720k/1.44M diskettes). + + Pauli + +From linux-standards-request@banjo.concert.net Tue Apr 7 16:54:06 1992 +Return-Path: +Received: from golem.wcc.govt.nz by banjo.concert.net with SMTP (PP) + id <15943-0@banjo.concert.net>; Tue, 7 Apr 1992 16:53:23 -0400 +Received: from csc.wcc.govt.nz by golem.wcc.govt.nz id ; + Wed, 8 Apr 92 07:53:36 +1200 +Received: by csc.wcc.govt.nz (MX V3.0) id 2944; Wed, 08 Apr 1992 08:55:19 EDT +Sender: hamilton +Date: Wed, 08 Apr 1992 08:55:15 EDT +From: hamilton@csc.wcc.govt.nz +To: linux-standards@banjo.concert.net +Cc: hamilton@csc.wcc.govt.nz +Message-Id: <00958CA2.83B11960.2944@csc.wcc.govt.nz> +Subject: device names + + +>It obviously isn't necessary to have different device names since DOS +>deals with this perfectly well and if DOS can do it we can certainly get + -- +>Linux to do it. Of course, someone will have to enlighten us as to how +>DOS does it? + +This person called "we" is sure gonna being doing heaps for linux :) + +I think someone has already raised the following points, but I think I +would like to emphisize them more. Has someone actually taken up the +task of working on smarter drivers (in particular the floppy). It +doesn't seem like a very exciting task: the current ones do an +adequate job. Perhaps the standard we need the soonest is one that +copes with the present, and actively being worked on, situation. +Maybe we could agree to get this out of the way first. + +Sounds like we need a standard for what linux can do now (or soon), +and a standard for what we want it to do in the longer term future. +Maybe we should have a "prefered directions standard", ie a statement +of where we'd like to be in a ideal situation. + +I've kind of lost track of the devices discussion, anyone got a summary +of the most promising alternatives? + + +From linux-standards-request@banjo.concert.net Tue Apr 7 18:05:21 1992 +Return-Path: +Received: from nic.stolaf.edu by banjo.concert.net with SMTP (PP) + id <16262-0@banjo.concert.net>; Tue, 7 Apr 1992 18:04:52 -0400 +Received: from amcl14.math.stolaf.edu by stolaf.edu (4.1/SMI-4.1) id AA22755; + Tue, 7 Apr 92 17:04:44 CDT +Date: Tue, 7 Apr 92 17:04:44 CDT +From: johnsonm@stolaf.edu (Michael K. Johnson) +Message-Id: <9204072204.AA22755@stolaf.edu> +Received: by amcl14.math.stolaf.edu (4.1/SMI-4.1) id AA00927; + Tue, 7 Apr 92 17:04:44 CDT +To: linux-standards@banjo.concert.net +In-Reply-To: Bruce Varney's message of Tue, 7 Apr 92 9:56:07 EST <9204071456.AA27722@sage.cc.purdue.edu> +Subject: device names + +From: asg@sage.cc.purdue.edu (Bruce Varney) + + This exactly what I think we should avoid! + Why do you need /dev/fd0.5 and /dev/fd0.3?? Do you have a 3.5" drive and + a 5.25" drive that are both assigned as drive 0???? + +Well, I agree with you wholeheartedly, but I couldn't resist pointing +out that canon, I think, (well, someone) has come out with a dual +drive which I have heard can be configured as one drive name that +handles 3.5 & 5.25. But there are other ways of dealing with such a +problem. BTW, if anyone knows these drives better, please correct me +-- all I've heard are rumors and seen pretty (ugly) pictures. ;-) + + Of course not! The + driver will know what to do with the drive based on the major an minor + numbers. The driver DOESN'T CARE WHAT THE NAME IS!! If I had a device named + /dev/gribble, and assign it the appropriate major and minor to be a + high deensity 3.5" drive in slot 0, it should work just fine. + + Bruce + +Not trying to break your point, though... + +michaelkjohnson +johnsonm@stolaf.edu + +From linux-standards-request@banjo.concert.net Wed Apr 8 08:51:19 1992 +Return-Path: +Received: from sun3.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <18849-0@banjo.concert.net>; Wed, 8 Apr 1992 08:50:45 -0400 +Via: sun3.nsfnet-relay.ac.uk; Wed, 8 Apr 1992 14:24:53 +0100 +Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa02687; + 8 Apr 92 14:29 BST +Date: Wed, 08 Apr 92 14:11:32 +0100 +From: Damiano Bolla +To: linux-standards@banjo.concert.net +Subject: malloc standard behaviour. + +Well, let's go away for a bit from the /dev discussion :-) +I agree with everything abc will say, after all is not a big deal :-) +( I still like the idea of a device name with some meaning... ) + +Anyway. Iesterday I was recompiling Cron... Not much problems +Quite straightforward :-) BUT, just one problem + +During the testing cron went on allocating memory and more memory +and using the said memory :-) I was watching the free space going down +and down and wondering what was going to happen. I was feeling safe +since cron was run interactively. + +At some point the memory ( even the virtual one ) finished. I was waiting +for cron to die...... Wait,,,, Wait...., Wait... 10 minutes :-) +Cron don't die.... In the meantime the machine is almost hung +It is not dead, it is alive, it is just so slow that you can't use it +and NO command can be run ( no memory available ). + +You may wonder why this is in the standard list :-) +Well it has to do with how malloc is done. + +As it is now malloc is like mach like it. You can malloc everything you +like you just run in trouble when you try to use it... + +I don't like it, or better I would like to be able to choose between +this and the other possible behaviour ( the standard one ). + +You may ask why I don't like it... +Suppose that my dear cron malloc some memory... malloc says OK. The +program run happly. At some point malloc try to use the memory. +What happens ? Cron die ? cron hung ? machine hung ? + +Suppose one "not friendly" user want to give me trouble .... +Very easy, malloc (BIGNUM); for (x=0;x +Received: from TSX-11.MIT.EDU by banjo.concert.net with SMTP (PP) + id <20273-0@banjo.concert.net>; Wed, 8 Apr 1992 11:46:56 -0400 +Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA14376; + Wed, 8 Apr 92 12:24:08 -0400 +Date: Wed, 8 Apr 92 12:24:08 -0400 +From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) +Message-Id: <9204081624.AA14376@tsx-11.MIT.EDU> +To: Damiano Bolla +Cc: linux-standards@banjo.concert.net +In-Reply-To: Damiano Bolla's message of Wed, 08 Apr 92 14:11:32 +0100, <9204081331.AA06430@Athena.MIT.EDU> +Subject: Re: malloc standard behaviour. +Reply-To: tytso@athena.mit.edu +Address: 1 Amherst St., Cambridge, MA 02139 +Phone: (617) 253-8091 + + Date: Wed, 08 Apr 92 14:11:32 +0100 + From: Damiano Bolla + + Suppose one "not friendly" user want to give me trouble .... + Very easy, malloc (BIGNUM); for (x=0;x +Received: from sun3.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <20575-0@banjo.concert.net>; Wed, 8 Apr 1992 12:24:25 -0400 +Via: sun3.nsfnet-relay.ac.uk; Wed, 8 Apr 1992 17:58:33 +0100 +Message-id: <08 Apr 92 17:20:00 BST ZLSIIAL@UK.AC.MCC.CMS> +Date: Wed, 08 Apr 92 17:20:00 BST +From: LeBlanc@manchester-computing-centre.ac.uk +MyName: A. V. Le Blanc +To: linux-standards +Subject: static bin + + +I'm not sure why you need to have eveything in /bin statically +linked. I've moved the lib92.xx.xx on my systems to lib +instead of having a pointer there; this eliminates (in practice) +the likelihood that I'll delete some gcc2 directory by accident. +When space is tight -- and on my system it's like swimming in a +bathtub, every little bit helps. You could always distribute +statically linked versions of everything for the cautious. + + -- Owen + LeBlanc@mcc.ac.uk + +From linux-standards-request@banjo.concert.net Wed Apr 8 14:00:15 1992 +Return-Path: +Received: from banjo.concert.net by banjo.concert.net + id <00308-0@banjo.concert.net>; Wed, 8 Apr 1992 13:59:54 -0400 +Subject: Unfortunate, but true.... +To: linux-standards@banjo.concert.net +Date: Wed, 8 Apr 92 13:59:51 EDT +X-Mailer: ELM [version 2.3 PL11] +From: Alan B Clegg +Sender: abc@banjo.concert.net + +I will *NOT* be producing the "ABC Release of Linux .95a" before I go on +vacation. I am currently over-whelmed by work, and won't have free-time +before leaving on Saturday morning. + +In the off-chance that I do get some time, it will be devoted to getting +my scsi disk back working again, as that is where the sources that I have +so-far compiled are living... 8-( + +-abc +-- +abc@concert.net Alan Clegg - Network Programmer +KD4JML (just my luck!) MCNC -- Center for Communications + +From linux-standards-request@banjo.concert.net Wed Apr 8 18:42:43 1992 +Return-Path: +Received: from sage.cc.purdue.edu by banjo.concert.net with SMTP (PP) + id <01564-0@banjo.concert.net>; Wed, 8 Apr 1992 18:42:28 -0400 +Received: by sage.cc.purdue.edu (5.61/Purdue_CC) id AA29068; + Wed, 8 Apr 92 17:11:40 -0500 +From: asg@sage.cc.purdue.edu (Bruce Varney) +Message-Id: <9204082211.AA29068@sage.cc.purdue.edu> +Subject: Re: device names +To: almesber@nessie.cs.id.ethz.ch (Werner Almesberger) +Date: Wed, 8 Apr 92 17:11:39 EST +Cc: linux-standards@banjo.concert.net +In-Reply-To: <9204071625.AA08652@nessie.cs.id.ethz.ch>; from "Werner Almesberger" at Apr 7, 92 6:25 pm +Needs: Your attention +Organization: Fraternal Order of Red-haired Milkmaids + +In the unforgettable words of Werner Almesberger: +-> +->> The driver will know what to do with the drive based on the major an minor +->> numbers. The driver DOESN'T CARE WHAT THE NAME IS!! +-> +->Right, the minor numbers should be different. This is what the driver IMHO +->should do: +-> +->An auto-detection mechanism for all four formats would be more compli- +->cated, slower and unreliable, especially in the presence of media +->errors. +-> + + But you wouldn't need an autodetection mechanism for all four +formats. The major and minor numbers of the device would tell it what +formats to try. Why do you want to base a driver, located in the kernel +on device names instead of numbers??? + + Bruce + +From linux-standards-request@banjo.concert.net Wed Apr 8 19:46:21 1992 +Return-Path: +Received: from bernina.ethz.ch by banjo.concert.net with SMTP (PP) + id <01803-0@banjo.concert.net>; Wed, 8 Apr 1992 19:46:07 -0400 +Received: from nessie by bernina.ethz.ch with SMTP inbound + id <25581-0@bernina.ethz.ch>; Thu, 9 Apr 1992 01:45:55 +0200 +Received: by nessie.cs.id.ethz.ch; Thu, 9 Apr 92 01:45:49 +0200 +Message-Id: <9204082345.AA20982@nessie.cs.id.ethz.ch> +From: almesber@nessie.cs.id.ethz.ch (Werner Almesberger) +Date: Thu, 9 Apr 1992 01:45:48 +0000 +In-Reply-To: asg@sage.cc.purdue.edu (Bruce Varney) "Re: device names" (Apr 8, 17:11) +X-Mailer: Mail User's Shell (7.2.3 5/22/91) +To: asg@sage.cc.purdue.edu (Bruce Varney) +Subject: Re: device names +Cc: linux-standards@banjo.concert.net + +asg@sage.cc.purdue.edu (Bruce Varney) writes: +> But you wouldn't need an autodetection mechanism for all four formats. +> The major and minor numbers of the device would tell it what formats to try. + +That's exactly my point ;-) + +> Why do you want to base a driver, located in the kernel on device names +> instead of numbers??? + +I guess that might be difficult ;-) No, seriously, I probably didn't +make that clear enough: /dev/fd0.3 etc. should of course have different +minor/major numbers too. + +What I'm proposing is simply a compromise between a complex detection +mechanism a la DOS and distinct devices for each supported format. + +Maybe we should move this discussion to comp.os.linux, because it's more +about driver design than about standards. + +- Werner + +-- + _________________________________________________________________________ + / Werner Almesberger, ETH Zuerich, CH almesber@nessie.cs.id.ethz.ch / + / IFW A44 Tel. +41 1 254 7213 almesberger@rzvax.ethz.ch / +/_BITNET:_ALMESBER@CZHETH5A__HEPNET/CHADNET:_[20579::]57414::ALMESBERGER_/ + + +From linux-standards-request@banjo.concert.net Wed Apr 8 23:29:49 1992 +Return-Path: +Received: from TSX-11.MIT.EDU by banjo.concert.net with SMTP (PP) + id <02267-0@banjo.concert.net>; Wed, 8 Apr 1992 23:29:33 -0400 +Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA18231; + Wed, 8 Apr 92 23:27:12 -0400 +Date: Wed, 8 Apr 92 23:27:12 -0400 +From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) +Message-Id: <9204090327.AA18231@tsx-11.MIT.EDU> +To: LeBlanc@manchester-computing-centre.ac.uk +Cc: linux-standards +In-Reply-To: LeBlanc@manchester-computing-centre.ac.uk's message of Wed, 08 Apr 92 17:20:00 BST, <08 Apr 92 17:20:00 BST ZLSIIAL@UK.AC.MCC.CMS> +Subject: Re: static bin +Reply-To: tytso@athena.mit.edu +Address: 1 Amherst St., Cambridge, MA 02139 +Phone: (617) 253-8091 + + Date: Wed, 08 Apr 92 17:20:00 BST + From: LeBlanc@manchester-computing-centre.ac.uk + Myname: A. V. Le Blanc + + I'm not sure why you need to have eveything in /bin statically + linked. I've moved the lib92.xx.xx on my systems to lib + instead of having a pointer there; this eliminates (in practice) + the likelihood that I'll delete some gcc2 directory by accident. + +No, you don't need *everything* in /bin to be statically linked. +However, it is wise to make /bin/ls, /bin/cp, /bin/mv, and /bin/sh be +statically linked. That way, you do surgery on the shared library +without losing big-time. Otherwise, you could replace the library with +a new one that turns out to bad, and you would be up the creek without a +paddle. It's not you might delete them by accident, but that you might +replace them with a new version that turns out to be built wrong. + +This tends to be relatively common in SunOS, when you are ripping out +YP, and replacing it with DNS --- if you screw up while doing surgery on +libc.a, only /bin/mv on SunOS is statically linked. So you what you +have to do is to copy the new libc.a to libc.a.new, move the old libc +out of the way (thus breaking all other programs except for /bin/mv) and +then move the new libc.a into place. If you're lucky, things start +working again. If you're not lucky, everything's broken except for +/bin/mv, which you use to move the old libc.a back into place. But that +gets really hairy. It would be nice to have a few more tools (like ls +and cp) when you're doing surgery on shared library files. + + - Ted + +From linux-standards-request@banjo.concert.net Mon Apr 13 06:40:52 1992 +Return-Path: +Received: from sun3.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP) + id <12687-0@banjo.concert.net>; Mon, 13 Apr 1992 06:40:38 -0400 +Via: sun3.nsfnet-relay.ac.uk; Mon, 13 Apr 1992 11:37:12 +0100 +Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa04166; + 13 Apr 92 11:39 BST +Date: Mon, 13 Apr 92 11:35:03 +0100 +From: Damiano Bolla +To: linux-standards@banjo.concert.net +Subject: Please Please Plase :-) + +Can ve have a new subtree for linux that has gcc2 + the stuff +compiled with gcc2 ( They need the libarary ) +SOmething like +linux1.0/INSTALL +linux1.0/bin +linux1.0/lib +linux1.0/usr/src +linux1.0/usr/bin +linux1.0/etc +linux1.0/...... + +It will save : +Time for the FTP admin ( It is easier to handle ) +Net bandwidth ( I am not downloading the new tree if I don't have gcc2 ) +Time for the users ( Gosh, is this program new or old ? ) + +Will anybody do it ? + +Damiano + +From linux-standards-request@banjo.concert.net Tue Apr 14 01:06:34 1992 +Return-Path: +Received: from TSX-11.MIT.EDU by banjo.concert.net with SMTP (PP) + id <14110-0@banjo.concert.net>; Tue, 14 Apr 1992 01:06:20 -0400 +Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA17914; + Tue, 14 Apr 92 01:05:31 -0400 +Date: Tue, 14 Apr 92 01:05:31 -0400 +From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) +Message-Id: <9204140505.AA17914@tsx-11.MIT.EDU> +To: Damiano Bolla +Cc: linux-standards@banjo.concert.net +In-Reply-To: Damiano Bolla's message of Mon, 13 Apr 92 11:35:03 +0100, <9204131041.AA20894@Athena.MIT.EDU> +Subject: Re: Please Please Plase :-) +Reply-To: tytso@athena.mit.edu +Address: 1 Amherst St., Cambridge, MA 02139 +Phone: (617) 253-8091 + + Date: Mon, 13 Apr 92 11:35:03 +0100 + From: Damiano Bolla + + Can ve have a new subtree for linux that has gcc2 + the stuff + compiled with gcc2 ( They need the libarary ) + + SOmething like + linux1.0/...... + +For right now, I would much rather request that people who are uploading +binaries to FTP sites *not* upload dynamically linked programs. That +means they need to compile programs with the -static flag. Even after +Linux 1.0 comes out (which it hasn't, yet), the dependency of which +shared library you need to use in order to win may still make it not +worthwhile to archive shared-library executables. + +If the ABC release takes off enough so that everybody is using the same +shared libraries, then perhaps it will work; I hope that is the case, +but I don't want to count on it. + +In the mean time, please only upload statically linked programs to +TSX-11. I think it will make people's lives much easier. + + - Ted + + + +From linux-standards-request@banjo.concert.net Tue Apr 14 10:31:54 1992 +Return-Path: +Received: from twok.ods.com by banjo.concert.net with SMTP (PP) + id <14572-0@banjo.concert.net>; Tue, 14 Apr 1992 10:31:35 -0400 +Received: by istwok.ods.com id AA14155 (5.65c/IDA-1.3.5); + Tue, 14 Apr 1992 09:27:53 -0500 +From: David Engel +Message-Id: <199204141427.AA14155@istwok.ods.com> +Subject: Re: Please Please Plase :-) +To: tytso@athena.mit.edu +Date: Tue, 14 Apr 92 9:27:51 CDT +Cc: db1@ukc.ac.uk, linux-standards@banjo.concert.net +In-Reply-To: <9204140505.AA17914@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Apr 14, 92 1:05 am +X-Mailer: ELM [version 2.3 PL11] + +> For right now, I would much rather request that people who are uploading +> binaries to FTP sites *not* upload dynamically linked programs. That +> means they need to compile programs with the -static flag. Even after + +What about uploading "ready-to-be-linked" objects like we did with GCC 2.1 +in 2.1shared-A.tar.Z? This way, everybody gets to decide for themselves +whether they want to use the shared libraries or not. It is also nice for +handling library bugs because you can usually just relink when a new library +comes out. + +David +-- +David Engel Optical Data Systems, Inc. +david@ods.com 1101 E. Arapaho Road +(214) 234-6400 Richardson, TX 75081 + +From linux-standards-request@banjo.concert.net Wed Apr 15 14:29:15 1992 +Return-Path: +Received: from TSX-11.MIT.EDU by banjo.concert.net with SMTP (PP) + id <16652-0@banjo.concert.net>; Wed, 15 Apr 1992 14:29:02 -0400 +Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA29122; + Wed, 15 Apr 92 14:28:54 -0400 +Date: Wed, 15 Apr 92 14:28:54 -0400 +From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) +Message-Id: <9204151828.AA29122@tsx-11.MIT.EDU> +To: David Engel +Cc: db1@ukc.ac.uk, linux-standards@banjo.concert.net +In-Reply-To: David Engel's message of Tue, 14 Apr 92 9:27:51 CDT, <199204141427.AA14155@istwok.ods.com> +Subject: Re: Please Please Plase :-) +Reply-To: tytso@athena.mit.edu +Address: 1 Amherst St., Cambridge, MA 02139 +Phone: (617) 253-8091 + + From: David Engel + Date: Tue, 14 Apr 92 9:27:51 CDT + + What about uploading "ready-to-be-linked" objects like we did with GCC 2.1 + in 2.1shared-A.tar.Z? This way, everybody gets to decide for themselves + whether they want to use the shared libraries or not. It is also nice for + handling library bugs because you can usually just relink when a new library + comes out. + +It is true that the "ready-to-be-linked" objects have the advantage that +you can relink when a new library comes out. However.... this assumes +that people keep the .o files around --- which will either consume disk +space or time and bother to back them up to floppies. + +Also, I'm not sure how convenient "ready-to-be-linked" objects really +are. I suspect that people who are willing to go through the bother of +linking .o files are probably also willing to untar a source +distribution and compile it themselves. True, a source distribution +takes more time to download, and takes a few extra seconds (but if you +have a fast 386/486 it is *only* few extra seconds, or minutes at most), +but I'm not convinced that there's enough of a difference between a +source distribution and .o files so that it is worthwhile to do both. + +Binaries, on the other hand, you just download and go. True, you have +to worry library bugs, and whether or not you have the right shared +library if you're using such beasts, but there are ways we can make that +easier. For example, we could require that uploaded programs use only +statically linked libraries, or we could require that uploaded programs +be linked against some standard shared libc.a --- which wouldn't change +often. (When it did change, people would have to keep the old shared libc +around until all of their binaries stopped using it; this means we want +to minimize the number of times the libc has to change.) + +So I'm not convinced that .o files are necessarily the right way to go. +I'm willing to be conviced, of course, but right now I think uploading +only statically linked binaries (and maybe shifting over to binaries +linked with a standard shared libc, once it stablizes) is the wisest +course. People who feel otherwise are welcome to send me mail. :-) + + - Ted + + + + + +From linux-standards-request@banjo.concert.net Sun Apr 26 19:04:39 1992 +Return-Path: +Received: from JARTHUR.CLAREMONT.EDU by banjo.concert.net with SMTP (PP) + id <15742-0@banjo.concert.net>; Sun, 26 Apr 1992 19:04:16 -0400 +Date: Sun, 26 Apr 92 16:03:11 PDT +From: "Jim Winstead Jr." +To: Adam Thompson +cc: torvalds@cc.helsinki.fi, linux-standards@banjo.concert.net, + ftp-linux@tsx-11.mit.edu, arl@cs.hut.fi +Subject: Re: Version numbering (was Re: pre-0.96) + + +In comp.os.linux you write: +>>have letter prefixes (0.96a, 0.96b), and the root image will be +> ^^^^^^^^^^^^^^ +>funny ... I could have *sworn* those were *suffixes* :-) + +Oops. That must be why I'm not an English major. + +>>updated with a minor number (0.96.1, 0.96.2, etc). This will let +>>Linus and I keep slightly different schedules, and hopefully eliminate +>>some confusion. (Where's the 0.95c++ root image?) +> +>Eliminate confusion... ? OHHHHHH shit. Let me see, I've got my +>0.96f kernel, (let's say) and I therefore need a root disk... hmm! +>neato, the root disk that matches is 0.95a ... sure ... Oh well. +>As long as everybody -knows- what goes with what... + +I think you missed my point. As of 0.96, there will be two images - +boot-0.96 and root-0.96. After this, the two images will proceed like +this: + + for the boot disk, or kernel, which Linus deals with, it will + be numbered as 0.96a, 0.96b, 0.96c, 0.96d, etc, hopefully + avoiding all the silly stuff with +'s. + + for the root disk, which I deal with, it will be identified + as 0.96.1, 0.96.2, 0.96.3, etc. + + Now, here's the real beauty of it: If there is a change in +the kernel that _requires_ changes to the root disk (or, less likely, +the other way around), or if Linus and I (and others) decide enough +progress has been made, the 'major' version number will be incremented +to 0.97, or whatever. + +The main point is: All root and boot images with 0.96 roots should be +compatible. This also allows Linus and I to keep completely different +schedules between major releases, which until now has really been +impossible. + +This has been cc'ed to Linus, the Linux-Standards list, and a couple +of FTP site managers for their comment. + diff --git a/Linux-0.95/docs/make.tex.Z b/Linux-0.95/docs/make.tex.Z new file mode 100644 index 00000000..8dfc1659 Binary files /dev/null and b/Linux-0.95/docs/make.tex.Z differ diff --git a/Linux-0.95/docs/mcc-interim b/Linux-0.95/docs/mcc-interim new file mode 100644 index 00000000..8181b6c7 --- /dev/null +++ b/Linux-0.95/docs/mcc-interim @@ -0,0 +1,155 @@ +To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU +From: zlsiial@uts.mcc.ac.uk (A. V. Le Blanc) +Subject: MCC 'interim' version of Linux (was Re: two questions) +Date: 23 Apr 92 13:21:07 GMT + +In article <1992Apr22.195030.8492@muddcs.claremont.edu> jwinstea@jarthur.claremont.edu (Jim Winstead Jr.) writes: +>In article aw2t+@andrew.cmu.edu (Alex R.N. Wetmore) writes: +>>2) What is the MCC release of Linux? +> +>It's the Manchester Computing Center (?) release, which serves as a +>sort of extended-release, as I see it. It includes many more +>utilities than the basic release from Linus and myself, and as a +>result comes on three (four?) floppies. + +It comes on two floppies, but there are a few others available. + +The Manchester ComputING CentRE was once Manchester University Regional +Computer Centre (pronounced 'murk') and later UMRCC. The change from +'computer' to 'computing' was made (supposedly) to mark a shift in +emphasis from supporting machines to supporting the people who use +them. (Some of the people who use them complain that the shift in +emphasis has not yet been implemented.) The University of Manchester +has been known to claim that computers were invented here, which they +were if you define 'computer' properly. We are a Centre, not a +Center, because (as someone pointed out in a recent note) that is +how it is spelled in 'proper' English (English + Irish + Australian + +Indian + Canadian + ...) as opposed to the American dialects. I try +to mention MCC from time to time, since they pay me and supply me +with equipment. I am in fact supposed to be doing other things for +MCC, and, also in fact, I do. + +The MCC 'interim' releases of Linux are unofficial experiments. +They vary depending on my whims and on the time I have to give them, +usually not enough, I am afraid. The latest so far, 0.95c+, +had (or has?) the following goals: + +(a) To provide a simple installation procedure. +(b) To provide a more complete installation procedure. +(c) To provide a backup/recovery service. +(d) To backup my (then) current system! + +When I first put Linux on a PC, back at 0.11, I got the standard +boot and root floppies, found there was no working fdisk, tried +edpart, which made a mess of my partition table by sorting it, +used the MINIX fdisk, and finally got a system going. Then I +started trying to get other bits to it. I decided this was a +bit awkward, and hoped someone would do something about it. +I also hate having to search through 3 ftp sites for useful bits, +the fragmented nature of a system which, I believe, was one of +the serious problems with MINIX, and having to compile everything +again and again because it was originally linked with some +defective version of the library, as happens often enough even +with 'mature' commercial Unixes. + +Theodore Ts'o wrote the ramdisk code in the Linux kernel. As he +remarked, it was originally designed to make it possible to store +some files on the ramdisk, and so free the disk drive for other +purposes, for example, for creating or modifying a boot floppy +so that it boots using a hard disk partition as the root device. +Both Ted and Linus warned me that the ramdisk code was inefficient, +but I thought this was no problem for an installation/backup/ +recovery system. Both also pointed out that the ramdisk uses +much more memory than it should, and this has in fact proven to +be a problem on systems with only 2mb of RAM. + +Nevertheless, the latest 'interim' release from MCC does manage to +squeeze quite a lot onto TWO disks: one of which combines the boot +and root disk, and one of which I called the 'utilities' disk. +The boot disk boots, loads its root device from the same disk, and +then starts executing /etc/rc. This runs a little script which +asks for the drive size, and mounts the utilities disk (which you +will of course have placed in the drive when you were instructed to). +The commands available on the combined boot/util combination are +approximately equivalent to those on Jim Winstead's root disk. +Of course, I have a lot more space than he does -- about 500k more -- +so I use a lot of this space for tar.Z files which contain all the +usual Unix commands I can find, excluding 'man' and the compilers, +but including, for example, awk (gawk), all of the GNU shell/file/text +utilities, grep and its cousins, sed, vi, more, less, tar, compress, +uuencoding/decoding, the mtools package for reading/writing DOS +files, and make. I also added the joe editor, for those who find +vi too alien. The format was a bit to cramped to try to include +emacs or tex or any other monster utilities, and almost everything +I wanted fit except Kermit, shoelace (which is awful, I admit, but +works if you know how to do it), and man pages. + +All of this fit on two disks, the boot disk and the utilities disk, +as I have said before. Now I tried this out on some of my unsuspecting +friends, who made interesting suggestions and complaints. One in +particular asked if I could add a disk containing the C compiler. +So my first additional disk (comp) contains gcc 2.1 plus the include +files and the libraries. I couldn't fit g++ on the same disk, so I +added shoelace and a bit of g++. (I supplied a new README file for +shoelace, explaining how to test it out from a floppy before you +overwrite your primary boot sector). Later I added another disk +(comp2) containing the rest of g++ (include files, binaries, libraries) +and Kermit, which is too big to fit on the utilities disk. When +I released this version (which did not include Kermit at first), +I received some favourable comments, but most people felt that +man pages should be included. I therefore project another disk, +which should include groff, man, and man pages. Note that these +additional disks (comp, comp2, and man) are not really part of the +'interim' version proper, though it is convenient to lump them +together. Not also that the man disk does not yet exist, though +the binaries and patches for groff are in fact available; the +binaries are not really usable, since they include only unlinked +executables, not the groff library stuff. When the man disk comes +out, it will probably include only preformatted man pages, with the +unformatted pages available for ftp in another format. The pages +are collected from the GNU sources and from elsewhere, including, +of course, those from the excellent Linux-man contributors. +The man-1.0 program does not do QUITE what I would like, and so I +am messing with it -- I hate distributing things that don't do what +they should. + +Contrary to my expectations, I did in fact create a sixth image, +which is called xdisk, and which -- in an awkward way -- allows +people with less than 4mb of RAM to install the 'interim' version +without using the ramdisk; they don't need my boot disk, but they +do need a standard 0.95c+ boot disk and my xdisk. + +I hope this clarifies what the MCC 'interim' version of Linux 0.95c+ +is, and why, when it consists of SIX disks, of which one does not +exists, while two come in two versions (US and UK keyboards), etc., +I would still say that, properly speaking, it consists of TWO disks, +together with a number of optional extra disks. + +The latest 'interim' version, while put together by me, is deeply +indebted to many other people, including Linus himself and Ted Ts'o, +who put up with a lot of hassle while I was working it up, and +Jim Winstead, some of whose bits are included. Also included are +poe-igl-1.2, lots of GNU code, HLU's C, C++, and libraries, all GNU +in origin, but with an awful lot of work involved in porting them, +the UU-, XX- and AtoB encoding/decoding utilities by Konrad Bernloehr, +and all the people who helped with testing and by reporting bugs +and even those who just said 'Thanks'. + +I would hope that the 'interim' version would influence other +versions, from which I will of course get new ideas and code. +But it would be very awkward to do the standard distribution this +way. First of all, it is a pain producing a boot disk. If you want +to change a letter in a text file, you have to mount, edit, unmount, +copy the disk to a file, copy the file and the image to another disk, +and then reboot. The present system, with Linus providing boot disks +and Jim providing root disks, is more convenient in many respects -- +but much harder for the end user. Perhaps it will change eventually +when Linux becomes stable -- but can you ever believe it will stop +changing? + + -- Owen + LeBlanc@mcc.ac.uk + + +[ The MCC "interim" release can be found in ~ftp/pub/linux/mirrors/mcc-interim + on TSX-11.MIT.EDU. --- Ted] diff --git a/Linux-0.95/docs/time.doc b/Linux-0.95/docs/time.doc new file mode 100644 index 00000000..b66ce020 --- /dev/null +++ b/Linux-0.95/docs/time.doc @@ -0,0 +1,104 @@ +Setting up time and time zones + +There are several things involved in getting time right under Linux: + + - /usr/lib/zoneinfo contains files that define what time zone you + are in. If they are missing, no time zone calculations + are done, i.e. your internal clock is assumed to be on + local time rather than the Unix standard of GMT. The only + file that you absolutely need is /usr/lib/zoneinfo/localtime, but I + recommend also having /usr/lib/zoneinfo/posixrules. Posixrules + is typically a copy of or link to localtime. Localtime defines + your default zone. Posixrules is needed to interpret the TZ + variable, which is used if you want to specify a zone other than + the default. + + - the "date" command can be used to set or display the date/time. + Note however that it does not set the hardware clock, so + next time you reboot, you'll be back to the old time. + I recommend that after changing the time with "date", you + use "clock -w" or "clock -u -w" to update the hardware clock + as well. (See below.) + + - the "clock" command can be used to set or display the date/time + in the hardware (CMOS) clock. Typically your /etc/rc script + will contain + clock -s + which will cause the Unix date/time to be initialized from the + CMOS clock when you boot. If your CMOS clock is set to GMT + (which is what I recommend) the correct command is + clock -u -s + +The binary time distribution should be untarred under /usr. It +contains lib/zoneinfo, bin/date, bin/clock, and doc/time.doc (this +file). Once you've installed these files, you'll want to do four +things: + +1) set /usr/lib/zoneinfo/localtime and /usr/lib/zoneinfo/posixrules. +You should copy the file for your time zone. E.g. if you are in the +U.S. Eastern time zone, do + + cd /usr/lib/zoneinfo + cp US/Eastern localtime + ln localtime posixrules + +Localtime defines the local time zone. Posixrules defines the zone to +be used to interpret the TZ environment variable. Since it's far more +convenient simply to use the right time zone file, nothing more will +be said here about how the TZ variable is used. Unless you intend to +use TZ, you can ignore the next paragraph. + +If you want exact POSIX behavior, posixrules should be a copy of or +link to one of the U.S. time zone files. (For non-U.S. daylight +rules, the TZ variable defines the daylight transition rules.) +However it may make more sense practically for it to be the same as +localtime, as shown in the instructions above. + +2) Once you've set up localtime and posixrules, you can remove the +rest of the files in /usr/lib/zoneinfo, if you're sure you'll never +want to operate in any other time zone. Or you can keep just the few +time zones that you might need. + +3) Put the correct "clock" command into /etc/rc. Which command to use +depends upon whether you want your hardware clock to keep local time +or GMT. I recommend using GMT, since that will allow daylight savings +transitions to be completely automatic. However the same clock is +used by DOS, and some people don't like the time in DOS being GMT. I +use Unix-compatible software under DOS. It uses the TZ environment +variable to do time zone conversion. Thus I prefer the clock being +GMT even under DOS. But some people may not like that. Anyway, if +your hardware clock is set to the local time, put the line + + clock -s + +in /etc/rc. This will set the Unix time from your hardware clock, +doing the necessary time conversion. If your hardware clock is set +to GMT, then you'll need the -u option: + + clock -u -s + +4) Now make sure that your hardware clock is set correctly. Try +"clock" with no arguments. It will print the current setting of the +hardware clock. Make sure it is right, and that it is either local or +GMT, as you decided. (If the hardware clock is supposed to be GMT, +you can use "clock -u". This will convert from GMT to local and +display it.) To set the clock, first use the "date" command to get +the date right in Unix. Then use "clock -w" to set the hardware +clock. Note that "clock -w" will set the hardware clock to the local +time, and "clock -u -w" will set it to GMT. Verify with "clock" that +the hardware clock is as you want it. + +From now on, the time should be right. If your hardware clock loses +or gains time, you can update it at a future date by the same +procedure just described: first get the Unix time right using "date" +and then use "clock -w" or "clock -u -w" to set the hardware clock. + +If your hardware clock is set using local time, make sure to reset it +when daylight time changes. If you're running Unix when daylight time +changes, the Unix time will adjust automatically. In that case, all +you need is "clock -w" to update the hardware clock. If you aren't +running Unix during the transition, then your time will be an hour off +the next time you boot. In that case, set the correct Unix time using +"date", and then use "clock -w" to update the hardware clock. If your +hardware clock is set using GMT time, none of this is necessary -- +daylight time transitions will happen automatically. diff --git a/Linux-0.95/dos_utils/bootlin.zip b/Linux-0.95/dos_utils/bootlin.zip new file mode 100644 index 00000000..58b9aa79 Binary files /dev/null and b/Linux-0.95/dos_utils/bootlin.zip differ diff --git a/Linux-0.95/dos_utils/pboot.zip b/Linux-0.95/dos_utils/pboot.zip new file mode 100644 index 00000000..8584490e Binary files /dev/null and b/Linux-0.95/dos_utils/pboot.zip differ diff --git a/Linux-0.95/images/bootimage-0.95 b/Linux-0.95/images/bootimage-0.95 new file mode 100644 index 00000000..c01cfa76 Binary files /dev/null and b/Linux-0.95/images/bootimage-0.95 differ diff --git a/Linux-0.95/images/bootimage-0.95a b/Linux-0.95/images/bootimage-0.95a new file mode 100644 index 00000000..1f06c1cf Binary files /dev/null and b/Linux-0.95/images/bootimage-0.95a differ diff --git a/Linux-0.95/images/bootimage-0.95c+ b/Linux-0.95/images/bootimage-0.95c+ new file mode 100644 index 00000000..eb8a9848 Binary files /dev/null and b/Linux-0.95/images/bootimage-0.95c+ differ diff --git a/Linux-0.95/patchs/0.95c.patch.2 b/Linux-0.95/patchs/0.95c.patch.2 new file mode 100644 index 00000000..53bb6b62 --- /dev/null +++ b/Linux-0.95/patchs/0.95c.patch.2 @@ -0,0 +1,569 @@ +From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) +Subject: Second 0.95a alpha-patch, part 2/2 +Date: 4 Apr 92 14:54:09 GMT + +The second part of the patches: concatenate, uudecode, uncompress and +patch. + + Linus + +==================== +M* ^3[DE^7?"*I$;"*:8 *=."7)XAI=*I2$F2.%)*=9Z42\HF)9<'4QFE/!ZZ +M'BN0LL<%99;R;@< XE)Z*>64;4HS94&,3.FF]$^F*3,::TI199GR[O.F3##% +M*4%8<\HF $:R3HFH?*!TO% L8$AP)[2"="G-$TB> "5@LH[)*&R-.F$.%2V +M)[62#ZJ.5O-+%R'Y"@;BL'I,!Q^6"F?"X7"=2'/LHC90-DKII)U2*TD@)%&& +MXB"2025V9)72'8FEK%4FF'R3Y3@$#\D((OGZ"C?Q$,F$'\DYUH%L6PFR\%9& +M27A1,J]P98&R5YFC-%>&>-"50YXU9*A20CFJC$/"*P&4"!Z(Y+=I#T>+ ]K% +M(:<(2T*#X7%R0(F=Y/L@)>65"HTU9<-RQ&:JK/*,6?B!_*BDEK=$_6/=(!-R +MTQ*%[ 07H7[2+=F?1%,N)S^681WB8*R28>FN[.24+)T])\N,0,IRR[2,Q$8. +M%\8%Q,4F9#]E HC#03]5(Y"0JL#K(=*2SW@RG(X](==SA<=BRA02N ,N4O^8 +M '6/QJ5ED' @!I P= OPU"2041^UC5:$,"?U8 -PT>)0$*IR8+?,_B*.]);LR\_@X^5MZ +M&XA+<\O5DW" !F"XC#ZFL[YNBDNV9;NR<7G!F@D%+M& 7[S.H_)Q,@*"DL3P +ME>))?C$W$R32:VF?VTW=A :7;0"R)8#/($65?LO.)5P)R6L\N\Y:Y>[1=]D&*%P&+Q&77S?;Y3$'=WF\%&-U +M 3^784O8)>7R>2E]G+M)+S&0N\G*8^>2H::\-"YI@T@&RR &I-MB-]840M)Q +MDE27J$!*4#,R8=!D3(+T4QX0KP+V#_>))4!/<=_M';5CY,-L9/W2"1D28$$0 +M'A%=6LMQY'D,7#0:04>B*@.5WA\C3S_/!["L5-Q)=2"83 )IKBR5^F1S%>F +M*ZF4:\LK9>;Q#1"*(]5Q>4A&M2:W)#;1*)F7=&>8!1N8/CA;! 93@TG!C-IT +M)"V8,LQDY023/5F>%/C(K) 4WTO<)0ES1OBP/&%R>5*80.@I#Y2'M>5FLL1I@1*-%:C5&+B +M*)N$\$F#Y2C+*))2C&$V#E\YUQHK)A9S+*/%//A@*Y-:#TI09?$R%+Q +MQ]H$B40 F4F%D;@Y6*D +M$S5DHC*9XGE%GZA>T;5<\WZ*@ ,^7EW CU>B,#"85Y@&-X9,0C;OH5?0*U', +M)?@+",5EIC[O5.;,).CI\;B9U,Q/ CO/G0>GH#)\ 18#C8&VD B!]B%"$)6 +M'N>9_Q:40K)5$@GN+N(8UTGZ"6D(9$IE63J"G/M%_6[W*(FLS[!CVE*:# A,]) +M,%Q769E'E]D' G2:JQ!Z"FYR-X"Z@3#Q(O WX.0M";YD,[G>$?7@0!<1*"Q: +MNLPY?QR+P'N@-? :B V4&6H#: :;IFZ $WC.P;QX@FX'<,T2E%C@07<#N!:. +MW/Q4Q@DVP+HRM.FA#"NTP%H('DAG#VXJP?1C&D8<%S(:,[PV H 49&B;!$N +M*QAJ+3"] J[*OU$F&&U.'79A,R/3I@D M5D6#/&L-A,\@([)A!B@P13;G&VB +M-FV;-05>1' 3#K#;#&WZ-LL$I(P&5XI#'NFEY)&U.-T^;W$W*X'JSKH;@T?6X-IF;P@'G9FW3I'/;Y$70 +M-E.;=2KZ9JZGM:G?,P W\U0W''3OCF9*&]R +MPS@@@3RMV(L0/L7N(7#>Y.J0$$Y-AC(JJ$3FC<%'"R +M-A4\LQ(U4+D'#_ M"!IM-Q])\,T4YSF)H4;_>DP&\LZ2 4X.9WW3PZD2\&Z* +M.'>;)9\B0!VE"A#O: +M&4YBW,CNH7&,YR!ON\(OY\* &WG6]$:J3=::>,=.YOGG#M3.DDQ& +MOL:$_ UK#J!,,2 =H$J ?A0K^ZO8@\.!A#+5B%I$4%(2] (B0!.@F#'HY)/E +MY@9K_KER3OS$/X=U,&PJZ YRSD:#G$IMYQ#WR^?75H+81Q%!T/G*DWFI.S\&B*.27;5@6Y"-BM(M?[@^5+J4A^Z'WDGHQ",Y +M,A9WKS4A6S*L+%CR>J_MN#Q<[!!&9[USFI2;8$N@"J@<)0#)"1[ 2G7%V&3A +M(R\(]BP; OF ]D0<:'=Z*GM-#*3)4@J05!*,6\2% ?AI$9ZGDM"$:,*FTWU= +ME(810@"B2BVI$!>K8U;YE&A6B$"C %J-!:!Z= VJBQ8&-*<5@,A3#F"(6E*@ +M05IWNARG)T5A7^3'*F(&E9">-:>EIR%J\*2 J&^=!RT2:!!L7/Z-W;GTY"K- +M )1-H)S02=63,1FOS!A)=5);"QVB!$"I"( %<"'(*N2!LZ;,9)NBH\FW@SFA +MGDR>YQY<$Y]P8N)0JH:04&X1=(LY1]4@E<- 47KB7<)V(9[@))>G/DD3F#A& +M($HD7T"PY=SGWNG*,7FF=%!#50'5T)4 XG;Q_*#@1: 6X(*9@99+3$'PO!U! +M)Q!.11] I\23A$*7".(H-E2?=)79IUO.@O%1<"),P?9(31*^2E1BZO#>R-(- +M"Y 7HD\G0NMSUG'88!5$)>@ 2@WVA?\AB7@G^ZJX+0"#K+H"D(0$0'Y0' ^4A*=@^?D;$GTV/Q\AIH_$1JV AYD_4'X^ +M$OT3C CQQZ0$]SGP '^V/Y]RXL^H1/ES4G'^? S0-=9:B@'A!+#BSTD9L!*P +M/^5D09S2'&>+F;%VVQX=<2 "_D^N2KS)(C'Q/&S\.[Y'!2+KE09T>\0S!1)),ZOZ3.9]F3I'3VI#"I/5EL=D UUDQG#%>I*\/U +MPAB>T#J'9X=K>!'Q9']2/#4?>H'2IT<@XTD#V'@2@3J>=H!_71H48P?4 V0P"1&&%:02= D1TU-N"N!!. 9J +MCZ07T $RP"*"M(+X$/4H0N4%?(^MQ2$4.\0"K?]8UU GMDE7Z.+J&1&%: O% +M0C5 *4_FH4["S>0\['D2XXX&,<^YQ=!D53&ONWE.)G*>(26>I\M3"90:"NL$ +M<: \,F^A:= "RK]]$J0B))D*< %D5G#4Q#:3!B9K[Z?[,],J(A)R>7VM DZ +MAN*>CHE\$MW3[KD[* ^@FEB3>\_2@$^'Q1:"0WJ*01^?3<\IPM33Z\FDU(WSHS",J@1[9;((GM0A=$*;Q1$O. '(JDL(>2/?&A,08J:-=3X>,K:()" +M"K^>OL MPVL %X(]NA_[37L+^5(NF7>2?28G'I_.S<7#_"!BA +M2O*B,I3R25(GHP,.C8L&!L2A"J=R*)80"O88DGL>F]:AMPN\YSL4-R#9G(P$>GQ2C)$\4R=*SWXD#E=+E?0*>/-".CAW4X'FDTX7Z +ME;2@25!YWLQJ.FHJ6A4'\]/D4KKO6:%2'^*1'. ;H"LU)6J[%E.>ER^ +M2H:CY ,6T_(-.0H4@#8U*/H$(@!F$/F@'-;)R85FE5:>G",1D"^4[03SQ"S- +M/(FA-L]SQ3%4YXF( \:E ):D4H*?IX*-"!&RX@'T (2>0M*J:+DNQU3T['L> +M/66B4%&@**6"2?@:G2MT,$V85T\T*43T.GH%0I J1_.$=%+9$D<4)%H2)8F. +M1/LG(=&4A6.B)+H2C4Z!F+:B35$Y*7$T(MH<90[$1+< :=*G)TLTJ+035936 +M1!FE25%Z EH Z1DIG7J&XL*@.-*0 !D4[1EC.H-.[DR8V[E"]IV33-<@(B7TV0.&CA\\LA>+SE!,F#<5)/A$\MXP'W?L'6V@/NFSA +M0N6C] (D:2_4Y2G!*BGUDA!*>(!5Q=!$#6<,C0$@0W>>5E(L:1A MH2QLM89 +MIB /C4!2W%FG!? D''OV1!6CHU(S:*Z#+?G#[/6FD'>EK-%]*)M43=JCJBM111^/0YY?:6])/$KS $M& +M)AU"QM(B*;)T)+J38'DJ29FE>(QGJFY@D5(JFVL:-2\NE11ZJJ-F35(H:,)6NE3R8>*5353@P4PH4V/-4 +M=]JD %&V))QTK=0O/8IB2AND5Z"=*=*47RHYLX6(S&JZ-<425$IG8F&2NNE"HA)Z5JI;+H:_8E* +M2E<=;-.SZ=$4#<*[@)LF2LVF3M-+*=#45VK$W!.)1Q]T6#']A[42P1,2&P2^ +M ;8 ?XZMYW'42$I,JBVIE&@ C3AEA%W*ET<T?^I JG> )BDR%J#) '8 /D +M WT0;!\B0,5J)X5!,DB&3K-:U ,X2.X.Z-DE#9WRV :2P5&:4_K1!H VI2=T +MH\(Z6,_9:<#T'^H$[==E3H5."0=!A]B):.H[/9P"3RD**@#,J?%T<]HYW4E! +MD49<7)[2'#TR.6 O& (T ? >E%#\CLWD\5% HZ#,-WH2^@MEX,+BF$6:R!9^ +M)24/[JL4H3EL^(,@H&JE%#!("![7Z:M3RU8IR@M^ 7:=*-.F0+@T7)4[Y0'0 +M3N>F]M)R%>Y4)FJ8\I_N3H.B^D$O5<#JSV%CVWC\(1*![%-%U)^C997\B/HLIGXX,*L=C@_K"C'9\#12,!Q_YJ??N?>HTBI]& +M4%^=.0Q,Q X#8,5?^T/=V&P1KJ;[*1%@@_HZY=MA/6NG72"?T@_5;2HP-1@: +MU]Q5-E1J72@G@MH(S #U3_^G4-,':?%4,Q4\I3J$/HFGSZ#?J>*4.9 \G:(" +M3SFG; #F#L.)@3K!^G- 4'6H$E2M!P6UOFE!A5QA4,VH_E,.*N'3@ZHK#:'" +M4;T-V,'$8]0+2!G3,XK< %B6XSPN#P,2%W:^4'^\F3:/H,\"T1-@0$0;M0$A +MO:@5RL!34J/D^5DK X$(!40$AT(9&?"G3#K$*TD)5"?,K("$6# &A( R;3Q +M(2:$2@7W192D#0!^HQ#"+((%78\+@ICB&P !61Y20#MY]H!J3B+>$FX +M"$@9@M&KAL#!$%'[[!TM@RRI-TA,:FRDG4)AD!H;*:1R"@ZIW%35Z1.P!8I3@XU, +M1I2=[8MG*G&*R18"D'71[N97;3HAYT^*@F1/]78!C)(3\(\84PZU-0 I$";0 +M=M1.YM0HP2.IB-5/M1?]4W\BV+>!*JT+O30%B%$J(YM?+;16A;4RF/(+]":@ +M4,>IRT=":AF 'JE01:0:0I]R[Z9^QD_"6""HJ!70/O1#> C@0?4(K-42\BI4+AOTTQHFE-UXRR 4Z] [M-J5D,5GYHB!2?I +MV?"GE$HZ $)-JL-/[78Y5)=. %4V%7@M"/!J(JA25 ^J=Z>$ZIO)YI92(*>> +M1TBJZ-11UDUM]>17U:O*4]5>]M&39TI(%YJD X2ZO;P)QJB@X;CDJSKK='F- +M51D%954NTUD5/)!6O4?:D6Z5^]05P&7UH6J?$*C253T#$U6#*I<'H3I2-:0N +M5+M@(=5R:FOUG)JRU$T=.PNKLU6%JO"29F?%4*P^A+)*C555VZ +M#NI"8;/Q7,[#$ $%*M3-+*I(B,]J1 K !(#'Z)[@ :2KS!WFZEJGN8KX# )4 +M@*BK> QP-]($N%=!3_&(/6/NTX:I"'*#/ JD*+>+2]#&0>YCK/M1G<+\[OI +MPI!A":HYTR_LZ!,,TZQ5Z4@ZN+!& +M>PH^F1UR%1140AKPP259%LQT?ZDV%?O4P6K;@; "2< 9>@):#ZPDG16LT_7L +M.DD#%L@H0'HT85>O(RHI3Q&G" -#E"R$0.2N*U]Y?0 LNAQ92/)M!309HSB] +M6%$%6U0'Q;?.QJKGP;$6*-,@_SJN6"@D-9I%/9P"65LKG5,:ZUK)ZE,Q39(6 +M66D&,J?.*5$"Y"$(%=F%=:I,:-" EH?U#J@F.F1Z.84+U 2P(!6)B" 'PG,1 +M!5H"X+FL43T%SU&;%:SYAGHG?*T1!K .3D@E5('*K@T?KWU*N&!\X7.RFRPD@JK-.J0NL +M5GDF!1[PYFI3@8K%4D3I%:*>DY+= J,5,1!60+4V*!B58$FS4_XK#G!H?;1U +M[[Z3IZI5ZZ153UAIS:T.HTI>N];.IZ45-8!II3OM6O6JH-84 !R0(+EI#6]. +MO1A.IM96*Y,RUMK]:06]N1RSG5K#.@6;4+*L3TW=6H.H9W-(J! +M-9\+W]:$P26SS9G)%*CL$+5/_+C$8W=J;/8D&"(25@YYAQ6JXB+O@)? LR5> +M")^(N41*WBXQ3-9+K"+^$OV: (]A(@>OF.A%#.&!$<6)R94[XJ)LE+E'3"<: +M-(EYJ8&?D2,*T*3Y@IS-68J\WXJS+Q-6=\UH@DJ0V;J7'FN^T0286EB<#K&F>DY +M7>L=%Y/2065QA# SD+RN7"JOE$=V(\ZORXAH]#?^:>",A1>D8W61[$@O _'= +M^=*.%A8:2ODD:KHUVOR-=]+39F +M'+6O7,?6JXKQZ^AI[,',7DFON<4BXP7-SHAZ_;;4''FORX2RRYI3=%%U>,0, +M7X6.[L9.#)!1_SI:5*!Y_SROBL:+8USORUC[^S8"8<:,>#, ;"K0].KJD\%B +M7P^P>[[O*VTQWDBB.:'%7@LM?$6HYN:M09(5(+1>&1>.I<:&8^\URG!G74") +M]>H"35@VZR,F"IN!E3(.';6,$%AH(^>U8H:C4<%"7T>O)%C6(B4M4>-ZQ?QU +M%U>OOD:V'^@5Q=> !3<69Y:P+(.,@6-A#"&'[1A0;?P$M1TI2,#)D1K"*6N2 +M'#^OR=C0J\,O' N@X[]&'7^Q_U= K,N1^GIZW<:N&7&P%[_MJP+VXFA%N\0* +MT%!E44U'6)HSW4I<2#@0,$4"30'P7,MP_7-N'2+P8WNOMT#%&^ -049A"8EOI*B$RE\JU1-G,A65?* I.!^'3&LE* 0!*,P! GO'@Z&C(V;TCCJ!ED2/0$A6U;1],R^! +M $0 -%G' B0!"N@)U,E6"BZRV<"7+#GUBE.1/,45@"DK I"E %F" ,"7"K@%6K;$X6*XN4)H+M 2X&%^$^%:=]D6"ERV)TM4 2&;6*$N:535!9:6R5-D49(- -'N5?S9UD<:H24+\N6/=&- +M9I&R?,JYK+!4\D", 2I4]D>B4V] %S6-CN^6,V"+28%IEE,#QZ I-#)@3YU^0WU9@Q5"H'8/!>099^R\%F:9'S.EK_K)YG! FA7=%2:,=0:@02+9 B*8L"&,]Z7EX@$KXA843VCKP3F-$3@0P: +M!N*9UHJO!)*H@7B5%1"P']$,%2/\P:$C6 +M"&)D<)651'(!>/!IPT\T#M:?(7]N0+2 C0UQ4K,'S)0W8JZ1; %;;"=^5R]2[^:4F]V9(&[1$.@(@!^4^%=-0@_/@EJ+>A@-&>'<"W@ +M/\,3T(,B(.V(I=+3@ (4"I1/')0ETO#V*9<-!9_"#(H.^:?UY_USRE*6#F +M[KH;+BOAVXBQZM,$;-\ZVJP[&XJR6(7"$-6LXBHIEJQ!.U)13_660736J*%9 +M#*Q',))2A:QC)!$2X+I\0$D2]XLNKN6!"\$@NE;(-_Z##A1%A!MWA6N+J..^ +M%.ZX:P,Z@![W#&"(4@S=.W@&7RCO0)LBOV20G.,6-/BW0('T(T!VB?N3FN-Z +M2<<4\]+/*?QJ<60TB3FP=\@J6 CAP"A#9; ]>H% (C82>!5DH+X)?+3? :<: +M68:U_Q)+A\('$FC'Q8B>"4TZ:(%*!RTWM1%9$"9-3(M)&J56AS$WA%%.TD7$ +ME;I*O:38VXZT^J$;HJ"X>IRYV8?+UFRKF[NL^#Q! 01(/PI\*JR* 6D>82T9 +M(PBX_PY/[AI@,]7%'"LP<&]40ZH1IR]7@B'+2VH"4V,$^4_NIRTU\;%:<... +M%U0>J+H ARPW)LLKU6<,F-Z <1V#J%0C>I$]943(J"R$(8%0+E^E3[&4NF#P +MH#PFEH?QIV9"DTJI6)0T;Y^W8K[%Q2 W7- X"%I6!B1),0=JZ,JA:>O$G6Q5 +M%,@%S@.(;JD 5D G !><*/H$"EK$QA#)3+"A,/*\%(Q7"=WNA@>I?BMW6C+5 +MZS),(M.NSY1PMY#6VAY-0I>VLP(HPJ4 3[OJJ/8D)%X%GH((A5%C)F'1'56% +MZC:DN1L\$JUO+1RFI0@B[E0/X +M,<:#M-LBH.VV;JNU16Q$/G:W#%N4@>\6J4O,D-XZ5(BW?#66ZJ<-KON[)6:@ +M7&^Z<@#H+?3 LTN[W>DR);8.V=MXT_8VL(E-^M[^H<2W:]U5 0WI?$LR\(OE +MBM:W(P*XE#P)?GOT 5'$;XE)6MW[K5#-G):[V]]V'Q2X6:6#+G2WK_1: N@: +M<+-*?J4$;G/W?ZM833RP=W2XKEK@K6>WI7H10 ;+@YWDB/WU,H5 +M >]K5*;E8Q!WB%NE,.*JM)*X.20'KD@W=;O,B.+"/OZ#55RJPQ4W/$+>A6_4 +M;CRV9($O+O,@C$M;L=A.!\JXXH1E$-=%C=M/\,U! S]B<-PC6UX*EDO'I>9^ +M=SN!A_WG/O']>[6;.=/KMWC +LFC8B?Z%\I4F:VM%KER[0/=!BG.KR["Q +M1J0ZMES40*4CEYLBG?&@[22\O]S?BC WXT#,C83\._@0R=Q/:,,6R_7.5:#$ +MLNY$1Z24CH)\$1W6-6J +M1]RY1(O^SI_W(S;/S16M!="CE"FX1>XAQ;D!WT+N9JK +M0<"W5A^-[I2'HYO*\>A":1=2M*@);[1B>P0=,"4A-9M2*-V:P(9BI9LRL.1* +M/L(<0%VR@$S7FMJ9(.2@=E6[4HV=KB'%IYM*"NHR2#UMRL"B;N5#?Y'4U2@P +M=8N?/U*J!<+!V$O5?3.U;_.ZJ)=D;P@(G*2PL]<9=\.Z*8"Q[EBAWXO7[4LE +M= ^Z?MUF*QPR*I3#VY$Z;W4EW!"7'YZV*@A891;$!,<4(@,"G%;!D#*#4N@\ +MANZT=8)O;HE)Y+/1V4!T 0V6]"^;8;);&L7I">H +M -*V\R;"[5A!@(NX;58I;K-*C%N2+77JM$NYZGI=OV4&$W(^$10$M(+>1)C% 0(;A0$E+9=4,@ +MY:87^),-Z$R!>.L!!4L\MKI:(( L ,5 W8OAC:2::Y\'=('*QZQ#^=G-K?8^ +M*R]S$<)P)ZB-_D3:Y>S*4HP3*0,+QG%@G!#WI0NTY@ZVJ%O)!R"">+O]D'?^ +M'[BVM-N[KRIOVSDOJ N( -JW4%]NV@P@2-J?(.W^11<7CU30RJ]@M1.88 ,H +M(MX609R7 :D@7#OV)1D,POK)/JF +MC':^?UN4[?4',0"7&OHR>@>X7\*C+W6WCQ19.*=%<\\]J%_FJ.\Q[Q3VZ6) +MU'@]BE[J+^76!_"6:JW( 88,M21:;T@ TLOC+1)8E+JY[R2B[S&I^]M>DB;5 +ME?Z7HA19: X2 +MM_R_GB< \#UW@B#JW>=^];UFT)R'EW?.6Y "_*"),$N'7TVOXS4HB +M?B487]S%;PHJ>0N\91$@?RT"O%3O1^7W/B3J\0&?B&BWG=^)R><7;WO[R5ZN +MGF9%T-^.3D70\*/^/>[>@*N[+Y#"[?6WZ-NR'01K=RA6^U!YD,*9 &>SJY>9Z>LN/K. 6<"38TPL#_MG*@,T AB%/<*EIHA0*WG9Q +M?0^T-ZC!KNVS]]M"D7=R4*1)76#I &-E(V$%KA74:W&_S[EB@6L&'D^, +M(GBZ_H2>D;V.I. A+544DSBV5=YJIV0D#TS2V0-/?]NW?N!/\/, ?FO]Q>X6 +M#TNIH@) PA.*Z)N5.(D\-KR_&J %<#L0&\BHNS7MJ#JL;UXFVR7X'&P"XAAJ +MGN!*P3H=D%?77H<1C@&O@+M)O20E$%Y# ??\O1)BA.6_N5Q-L&)I$SQGLT3Z +MA#FZ6;8HYXG'7:<#(F2@!G "#L=$(!V*$SFK7$(/MUU2[8XY(_)W?.MJPK' +MF,"E9>'?RE;XL=$51@N#A>%U8F'WP5(@+8R%L I[A;/":N$'*5M8EHL5_M:% +MA0FA21UE%Z=@?E#0F%YD=A"T3J/ L"MU)YQAZ@E_">EJH]N1W=!A=]$KCZXDG'H[ ?C01,[\0+:[?AS(%P&-DX8A/$2".'=Q&_W2L@0;I1( +M8F(6$B6(\&X79$L8V$E2A.D)%N&+8!]89N$1W@@'@CO"V]\806;-;3 2'@27 +MA(?"*.%.CDI8/=@2ABOYP#!W[:69,&ZI)@P ;@[#JG3""N'&,%S*)\P*GO0* +M4=G"C&&C,%P**8P3/@MAEE&CN$C@E+X/&RSFU[@ +MJO# XN$!$7FX_KL4)M<-A3U(B&'I!P3X21PTBA)S,*YKW[O +NE6@G'QY7UJ +M?%.^>E6/[UL0Y$L(;DJ0?,4Y"T&4;_MR$*P"8/GZA"!--H^\B1%VR.D^";\%^X)K&)T8*Z#GT6V*/?U'P(.M( Z+;,JW!4D+C!"\.P6K-.4,(ABF<9BN).!J/XTAJU:0Q# +M B'%:P/4 6>,3CS=_)3ZDS+%^J3)':?888BD^!2/&\W H^+5$^VG5+R[Y(9M +M564 D9-AH^4AK<4" UAZ6 LU?7P +MN42ZK^%$1#D$#0%@\8-*<,@.I_L A8,N;L28)-;%;M%CU^W(7RNP?1J^9,W QM*/B918S?NS+>>2 +M=6NVUP)2 6(2OP.NC1@KAW^V%)^.UP(8JB]Y +M!NBJ I^3\9LW97P)5H=F"=2S#]Q2X8MW82$8\1IH%BR.T^+G7+7XT(DM;OM& +M+\8%W.+E4(G@6UP,#!=_51@?/XMHH+D8/OR<2Q?7"H(A[.)S+:&ST@$O'G"Z +M#^;% .-CCS/(5OQ2F(F6I/#%G#'X+9HXNQ'E)!BGM:S&R@.$L7E"83SX_=DV +MC'\4#V/(;S108AP2H!A+B2W&!E&/ C-P8\R%Z!COC3_&4N*0\2UG9'P4("S) +MC"_%-6/40,M8UC1 P@+$C/W%D&-_KC":I<$;EQ($R;%9ZSA1%*@ +M0,N/B 3&%.' !H<"!=".;">&&:9[,;- 3L$$4 '0 /(&J/:B") LL +M*_P J6/-P.K8V9.0C Y* _FVL.-'\=F864 #4 %4.G#'WJHAP.XXYRD%"/G. +MZB[')BV4\7QS=&LNDD3>W^)!N<(>9$1 V1!N#3R.6_%Q.9RE0&F$SKIS(!^_ +M7<%CZT-+V#LNALA"^^'$5RYY4]>#*YHLX9IU9;B"\*@+#U<"A1AQ#$!&K $! +M!56H MX).I3IXX]PY)XJ(@CDC#FR-6*.J(R)6Y:P_OG C,L[AR +M7 ^:\#%!8GV,XUI(=&6"7/UC(Y61ZR+1Y!K0V][R$=Z(C ),- +M7BME9SS :T)S0G9#-N.)5^!X%,TY7DR3G$E3"#)\5*.N!=?\\141F)A%_.2Q +MR;2NQL12WA5'EQ=QY>5-7 >:'>2"Y@=9[QI"+F8N-'/(VA7!:STQYMI3,;SF +M$\>9/EEH=HOK8S]4+3#Q* +M'HRP&=IO9;I"$06N,PE4LM15]EMU92)?7;6(H+R%JYLLBOQ%Q&&@ +MDFUD=K+;BC/1E4?H)+O^5@2V@C+B"BY/=3)5NB+;$:W(F&1@7B#YF#=&-F:" +MD0.O#\TVWA?YA^S-?&F&DM'(&$TA;.+QHU66\$I4 +M^_Z-XS_\F;:OVXAS1.J%_^(RZ[W0GLD1B5;GJS1Z;1ZQC#]WWZ91XY@^N\<4 +M!K(-O9B3\D-Y#_OB^_ZET"9_W;Y8'Z%1[@"8,2DCS%+*"S/NWYH/CH;CN_D) +M:6#*A5B9LCA6.Z.+]=_\;#K*$S_>7PU&P.A+&"#1#:\I 0;P@X3"FD +MEE9+#R6L;]&([M2A4_7ZEF?!O"220BTI'-R&,%:&=23 ?&(.'4"7D)$)!J]. +M>N%%>51 K3*DF[##\:KVNW13ZFO.'@L)TW.*8'!MRB +M;:^Z8@QY1XL317HC&? +M04!)L2DOY(Z0/-4WMD%Q5+T"V+%,4Y2H[#9F3MDYNR8B:69I@KA@?^QF+I*Y +M<^/,#>3K!)V9IOJ?> O@F1M$QH(#2/DVL>!G?C@!FI$ @N8O *%Y4F!HOM8Y +M HL\@5[S,*,9H.1HUBTSH=96DN;>(:6Y_'./XAFB'KO+BL=N@JHB]3A>+B^C +MR<[+RZ?T.G+#-XB+GY9H4!!"O\F +MGOJ M^ ),+!9U8L)1C"CYLD=0$BZ=N3%$R1!)O%3$!@DLF>858LO(SC(@?#@NG-#&![_HF!$,VE)V//Y."?I-N=U[>9 (-+H=T@I/%CFEAT"N."B43OXR:E/)83> +MHW QBBOU/MJ"K<&K'S9KYYUBZ^4D?E@W,A: NB6M/*1=[#V[3VP-=A>6FVP +M"(K,XYV3LP.,#?;@D@2SEIT_KF6Q7:E MHEO7LXM!A8#U5IE(!'B%*H_H#:1 +M#V0A_@F&&-8$)M!%J,XZA'C.I"^@1X\@Y(C#B1DZ>X1]YY$DS!A-!L :0 C"?$U*0 ,XD ,D3) +M 2 T"HSQ[+=NOJPGJ"\3<8\ #EX$C]#9<4)T?B@9G<>&+DZ?\]^9ODM5HK(^ +MG5E+4>>P@C0824%W#GG=#F5+%2%JCV^I]KQR]A3F#2VDJV6)4VOYH?1:SM,= +M.+O._CNP\_$6#3%V9D"5"+I5PLHB8"LH$@*OOL].9K4&K\B_SB6-):!>9 77JO=8$6 P( +M @F!,=*ZE!CUJ]9 -4S1FM #LJ;+$R/0U[R+Z^P(K0!*3T-. UW(YL$2"*1F +MGRFFQC?)D?>9#<@""#^/G_<^Y>>30>LC_EPB8 +M">#':$T^[4J 6#A9IIY5;A*R=B ;;A.C$Z$2V)D@^B7_<&R.P< +M=C;1?UET994QA 2A QI]F&VIM0[O#,+.F +M'FZ-J@-_;",36 B0370!TUZ&MVC_XO(!#[UX:]\=(1^R3TQB"@E*,JF,5A5; +MZ*ZRLZ8?06AR/3":5"'X('(CQ=D62C2:$8D$> )< 9P %L@6 @^!:2@/3 "X +M0=8>W=0+B$$4"\".SDG\YVPP)@7F1(4B$_*?F\Z8%,H$*(NO1(%(L:%RL&L: +M!\82,X<^V5^%!V4FF$>#\O@)]UYP0:# 3%!#*? \5=\Y]1Q<;'_N.NN?([WQ +M6T:ULD6,-(%QH ,X!075@Z#-^H]W$.KQ&3V6_0*X9).&*5DJAM/ +:N-/DF+ +MD@(%K)30!TO:(V"2?NDH!X@*"0"E13F2D]F$6I4F_=*;276/OK!(JZ3!.@ $8 +M>3HL6*K5E>XE0_4>H5WJ7@1K F5 K2[BTH3NA!C 00RB)FG"\^-)8O0%\-3V +M#VUA@$'7&48C@$3('T-MS*5]"@QLVS3(V3;AC/C2S(&_M.[-,&;0.-C5 +M#IAAC@'"0MYHGG"8G@H=/L*Z2!]FU=.C=H,S:E!!"?C.#ZZR@A1B<^1Q$*P0 +M!RK3@&FUCCQF,4T<B4$*G@U)9H4T' +MIM1,G* +M4/4"[)VX=.-I+FV2AG2!/D$ 1&GA4D&ZJ2J_Z!T]PT0_>NEX,(2Z'>T(P5J( +M*;HI+0 HP&>R*!U);LEY(C82(NK,$XDZD_B;V_.R"%J[^@3>!+U@*2T\6 Y$ +MIND%\Q_A14^#K.(& !2,ATP%MZ,FQ>%V_D)QH-TR S70JY;F@;T 6!#3*"OT +M!0048P/[@P&-:1OD_4\H!Q8?!B?:+0(YZ8!4G)&-YK!)B&F_]&JZ-@VE(WGZZ3GVJ%DZO"RHKQ6D-2FP$*)"$=/_416DVM9LIX8PGWJ9) +M$XP'LVKO-&J:0()#R1OM!"@#R;=0]7::5-V=-E5_I\_4JNK"$*LZ6+T+)96\ +MJHO56(^WF'7Z/)U\&T]'FYI"U&KWM'\ZHR2?/@/0I]G5]FG\M+EZ/3VKCG"@ +M =;5?:-V=8":&^9^4G6]I%J\ ")N$$XMB%O' ;RX""#5Z,_'!67V=_G?HFO:KQI7L-&''K,?LI.,/H:-JZ'5V+ 7BPM@6K6]'L$FL.R3A$9>F[6G.'##KK'D*.V)?!H +MK'-N2"]65=*:5GVMI@R@J8%C'X-!#HIT/(W FE5K\$02BYY";GLB,:;P.B[M +MNI;5S2:,'% @D+&L)L$8K3_5%R(_3JF069"QCEB+'.8%-&MH6,FFFQ!J;2 5[6QVE>->GZ 6V+4 %<:R;32T'19>N:O:IL/3,5 +M&L9,D&O R]WZ/J]V_1:=LVP[CP[K/,)V6L_3@7&>(VSUJ]2 +M=/K6507.=>(CC[.R3E__K'G5ENN9=?O:;2"Z)EG+KQ&789_Z==>C9#V_UE4C +MIUW6]VO2M=L@==TSDEFKK/'7N#&;=>+Z>&V^YEL3!'C6#4'U==#:TV1L(5H' +MBG;7[Q&D]9R:3(VW9EI7%:36X!WR==2:<(38.>]4K84E!9ZF-:P@:XW!-E-[ +MK;/5(H/4E5PH0+V.;E5768G5*#?3U=;Z;.W645L#IE]V;>O'T=LZ8AVWSAO1 +MK2/6=NNMM7<:<+3K+E\GQAK7)&SYTK(Z<@T9)(WUKQW5=(#+-:M*@KVY?E_' +MDE"=V^JE2E5T8S+V=L=](=28U=L1Z3@ 'D 'D +MC1BXRS#KVQCLC[.L!EF'K-O7MF@D"X+&'XMX:QZ9#FYI*@A=X%\NFU.''K+L +MLS<9>>220-]$/,?6[$,O, .UU=FM@ .#O>JAA34!"6B2]U,<1B,Z"'#1GA1, +M$,IRAD$L$4Q;%]IW6E%HM1P:"(W)Q8FBR*%3PF%; +M'B9+?2>NKV8+J0TNL'BRG9C:3B:G=LP!JCWU*>!.M5'()8E;HPKJU7Q8^7Y" +MC'LB/6QN05-[6 N(#@7M%";:A.AHFT4[/OL%$&E7 >ZG)FF--C1ZKHW1MFOC +MM5?:G,"0]DB;[FG2U@R@M$T8>>VO13&D7JM?!XH0FJU;+IMT\P&G7!73:N>,A0$_;M3*5 FIK +MM8?:6:6B]HGBJ W65FIW*& 6:VVA]F>[5.'S_&J+5$H2I6*U=E8;K@7;)B;U +MG6H4M.W?-EM"K&T[(FN7B,_:Y(.T]O6"4(##!IR"M(:-7.TC0KXGN?W08$N8 +MK;3&KD_#Z6OHJHW;'F[WCOAR0MJ\0%P;M1T]UFN/9=G;WRH:2'Z&0V=N,7W( +MM(-D)[KK+ Y#O>VA90^FMK&=5P*3#E%"[ $)J6RH ;J>E!R-7ECA$RIU@E)C +M9E-T_NWH<4D@1W # '"KD' 2 VZ%<1^)P6UU.HRRM<^;15B+8W;;;=$_X6XG +MM4,H0@3P]JRC!SW>GE"4MZG;>SGO+RT:02W!:&R;NQ[;DP+"MJ* LLU#N&S7 +MI=50@>-_=-F7!]7X#>6418"FE +MHR]T5@)! Y ;?"F<@+X=N@.30"3]!. RQWL:@J U[;XP]]2- U+Q<7.;I/?VYS;OXLS WICIS8M03=EFY"-V\@QD86T'-G +MNL,#F 7HQX':SOU,I!=HN9$[WH%AE]F&THWJ=B"$!\+?GCG6' +M!ZXRHFX.K=D&T\82-!T@?T$$$PYX29W9#A$>$@+#$M<6P %@AF<7A[WJ_@+< +MY%H"D"M+Q&*M.RLQL$[AN6T1\.UA5Y3V*IOMEF\_JHL\]6VX$XO;/ Q(J'-O +MN]_;1^XD-YNRO@WN'G^4MDDKJ>H.B[)U Q3N[CNQN&/$]=\@K7<6'+U1\78_ +M2S= _F[[=I,5$UP>/BN5NU-TX&AM*GK "/ $\'9Z:O-*8@WVTBIB2*F!B?&Z#1'CVJ,-YZ@ZH/S[B7IO%$&YN$4T,>[N(7?GA([ +MMS+;M%ETMS;5L(WDS@*4[V[-P\T[X/WS#@]XO'O> N\>M(5YI:%8LN6X +MZ,9,1.]O@=1[NJK2D/+9;4 IF_4]PWCB?.6OHT" +M!23?IV_!)ES;0PN.=NKLM&?21F[CM]R@2IL^.EL(7E W6XK[;$)^(TEBGYC +MG%PZIF\?1&YFSV/]7@WBOE/;K*M25E21)$WZSGU+3E+?!M'5-\6A]9WY%@XO +M!J8$@ +9=X/;\_W@OGV;OTN$U&Z]@+7;T8WM;L4=;O$:5E'YCOU/;VN^)PP+<],W\]GZ;OIW0 ^5U0RV[VM'_IH [ +MP$MW"O!E!0+\ 1X]CH!;'B;@J>T*^+'I^QT]=C"+> +M*S YX"M]+F +MDUC@D^_C8 Q\USD#-P)L@+BTC34>N$:KI3W?-N]IP6U47/!'=7Y[U*W8YF\K +M-L'11(#-0!$<\FWD3H/# Y7@_6\D^!O<"FZEK26-9^%.*XHQ.(>V#$[1/H/_ +MNF #:_#1=POE""Y ZA[ P:'?&P(U.!S<#B[PSJRYIT^N%X #5X(#X2K +MO7<(@/!#."$\$TX'5S#;(N[@16T2]\M #[[#X(.OMPW1UU/)CQ$<%9Z1K8%3 +MPCGA%7!&.-Q)NXT9,U#OP2/AIW!QM"4"<\I 0*5T*Q +M4DGA<9!/ GLG"$!OMFT_="DA, N%LC@A%M'JP0%!82D6/XLJ[V);""X'/^;L +M$%;AW7 BP ZA L[BJ',KA&X'9I3\QDH2-3D"!X&GMJO?#' 5. G\6V4"CSF@ +MP*/'\G 0 !1\V*78;D2#HZG@K7 1$*Y.C_T%]X'/MX'@Z>C]]UT@RWT$3X(; +M 0+@Z&XY>$#\+8,(]X#/E?;A( I^#]\AY"197Y[PO,]/7#!#[O;G0 2WX)W +M='[@MO!2>"3$W<*#X19XJC743A X:R@'Y[HLT2YW\#P[, PO"KN)$[=XE7 +MPA?A.?%9.%@<&9[_+HLOQ/O?NG#)CUH\X6WN:HLGO-'B7?&X>-_I?;$OXHFG +M$Y;AS7!$Q*1DQN>WG#X(S@<,RX.%\^2 +M%,KA^FVVT1HMLR#ZCCF D_>\F%Y-&R/B1G1*NLI6*7#@D^??Q<0!DQ3EAG?' +M1UX?\DEZ@2>BIW&3E1A@N1U ]PH\Y6\<#0 '4'P*Q_'<#ZX\@./+O4TR>(W7 +M[CJ&-F%>A6&\$92=!8D5Q]DBQ-J<+%VR.OR[2 #D"( ,J5-(>#?U7*!2" SX +M45:S/8$;^'.\.\X"J43PQ*M!F^<@9BB @7-#ZLY9('3N#(P-9Y16(U3 +M#%KC8UGG> Y<-F[+FG74QF5DHKS7\ +MQBF/R_$7> M%0!X;YU6T@YL\( VQN'@\+T >7SGP,F;2Z?$C &P<])3T4$R +MQ@_4\''S^'R<^&A_8[QZ9SGDH"=G,.C),-X/O\I&QXDJWW$; '-\0ZX>'Y![ +MR'%UAB!_>-=015Z[@Q0$NX@ O_ KN"<<1ZX#OR=9,6W@3'(C^83LGN1@R!1) +M'O"3Y&\B>9:\0TY4^9'SR"/A'MJCPY#<(_ C]X[G@83D&G*/ )6\.XXD5R/H +MM]G@,7 :_AI(H9^?#;#RX$R%1DQE?AG?(I0&9\*^X&'Y7C +MQ)G?LW"GN(B<0XOTWH;[P9T C"?/X%12-"! (@*8Y>@)@*+V!*YGJ'T[VI7' +M'.Y(X*#W"$CR,98*.R(WRA'CD'*]0(W"PPL-IY2[DJ?A@XG(>.M"4^X@_XF; +MNHO?GO+.^%Z\%9[PF?BIG)/.*J\*9ZX?8K/4$$ #("HN%T<* Z.AI6O +M!_P*1%KO@#RPNB#XR94#!7SEM\99AZ]\J)A1"I9S'&+9/D1I8:-KCO+H>F3[ +M) 0L20=E3G%[R1PC <%,GZ33#D$\V\8V[D!D,V >((@G"L.".2/;CHC$!(S$?=+G,CMQ%@LADT5YJ; +M!JH@&_/\]RE\';H*7YE[25;EYW*>^1':A\6QXJUYF? +MSJOEEG%^=YQA%;XTY[RMS5'GL7.2-F:5#0Z.MIJ#SE/G<7"N.>?\:UY,,9T[ +MSM7EP'-@>/=Q6XXV+Z:HS:/F!)&29#H< S$HCC*$FE%098J,PUN#$8HV()PW +MS1/>0 HK@/)CHE+E@@*XD*VUW0["QOL#9H$"+0AW;%OE8W,C=R5<6"G9/%PP +MO"D%\?):^1AJ1_INNOI\0N?F9@6?:LQ"'GF@D*&TBPF=-.I6,\:7L !_LV4I +M-E84<8(#^NV(HA"DUN**BW,3_0R]$(VC6\OM2/YHCX2B7MQ%+I+,KU(ZH$I$ +M=,D%BW$%A%QT? KU>ILD( VB*=7L>1R;),$])P)XS]7>A@KQ^3""?,[>,9\W +MDM'G],)9!5Y]7 +M3"SH[@/_N%W$0%#X\S02G!9YCZ] +M$(<[R&A9-D!6).DSG*E+.ZS0[N%6]L0",&#+!'5/(&@5U[QATN5D/0:H&I>E:=Y?Q[%GAV +M="[/-%ZP>AO@\1QY'LE&GK%V<)_^QKUS=$?3=M]8J9N!(8S170R;_STLT &5 +MPPRWO%#UE@)#+A!5OZCS0M_-5:[QKG>;4T#7Y"1%%IC=U*5WRLP)!V#\>>!N +M54(+%(>=-Y%4.A(HHF'1-\IMZ@FMEHU -[3]4$]\/5ZZ3-WV!%,BJ_3?X6Q* +M'EQ2(&F65%BR4&LX@D^:"&P&75L30/V)[0*-5=F"PV[K72APF.Z%O7,P0@^% +M<]0=L)/@^DUAN,XLT+6$>B2SG*,7 '"=N,Y<#ZZ7;0RB_.7?>G/=&&%<7\Z- +M&(G5,0?!&BU(#2$A_ANE(6X W75;T*W'(=%=9Q:0UR7$XG5KGB9TNPY>EQ"; +MU[GKZ'5F 7N]O/Y=#Z\7U_^4XW7X^E+XO=Y>7PJ+U^?K[O7Z.GI=O%Y=GWA+ +MU^_K.U(JPX']N<[>R0_*,!( -HZZC:Z6+?!1>+"+ %[2[ILKU6X=I//6E:PK +MUV\*-@+826("LX!;UXB5V&]BU'4 =RSGM[Z%ZD(1V!,+:.EM>DI=:4;W6R&" +MTVLPX'YPZ.U NS3XS&!?4 +MV8O9B1;EU0X[#CY!.2 PD@DN=!;M/O4V^Y="B@'VP$34 +MV=4.7AD8P:7]3&9)6%"9_AY#B_818YT=+2%6UQ.,VE.I+H+(PJG]]S!,_>,0 +M*EBB,3Y0>]&BU4XE@$O8<= 2O6I.Q*;]='T@7&4_VADWJQ)%>Q3L,1=F]R< +M7NKL* N>7)A]7N!AN+1?V5E@8?8N^^L#O0W@YH1NMHRZ"4)):A&Q*_%)U7N< +M"?0)$HK_@W$%K@7^&>6,?,<)BJ>2N-5GH:-F;SJM6%X&[ )/SIF]K-#C+%'I +M-Q+I;?94:LK:T2YK[X_QU"7M2P(7@5?FTOZER+1K"//MXC!V?YD" RXW(D*+O>&3DB VKXCM;:K +MM8"_=%#.%HB0VY[W,('F-,+MC8=Q^YOZI7-N-Q.DV[7@Z_;'4+M]ZO1N3ZB; +M >3M521Z^Y93JAEL\3/&''L"8LX"YO>0GL(L.JF#GV;LX%?@PS_6@%F!<%I: +M(UEH$EG1-YD9-_PXH4<.-%S7&4JOQ)A'QDVKQ4W*E#B3NA;.5HS]&B6/PF6J +MBS2/6B"&I'IV3$M>0+P_@1B2LT[U>N11O?Z'9&$V8C9*L$DP+:?5\=Z=G-:- +M:W]WY&Y%&&& +MUH^Z]XD\P=] IFO^90Y$=E^ZA0GO>FV",=">Z%C*AK%)WME8Y47K/Q(G+T?H +M,:>7X_>80*N\[[Z45#49+WV5@7>4P> =VAO2'=.")W65XLG*^Q*3[5:HY/9H +M(-OOK3B4UCE)_]Z=O!CA,AOON,?$^PH#0"M^1VD9:".6?$#*N^,=,/:(U+S; +M*@OOC'<"/.2]_.@':,"3LW"9:KLQ[>3=I6)ZET@>)@ ):W+S._%R>OE^IR0* +MWG&9+&@+_/U]5ZE_7U9&W/[O%DCTNP!^6:&!%T@NWA4:/7A[ 0/^_%X>X&M) +MWB/P=9MWY1*H0D P"A +MWFUZL[?:>\\W+N!Z;T)MW?6Q48?Z65/,[DC_,$;3D=]W9_>F'C$:?7PT6$'0 +M:8H8^[!T]J$ ZVE=\$Z*X +M$ZP^' >-A5+FL[ZX*<J0-ENP3Q&R5'[G G&\D!*S"%Y(-E]\[:,3DNPLI( +MO3)%W2F_2G7=A<6_4U!MJ)/,3IJY"H ,98@Z +MULPZA0(7[T_-K)/F:7;NYLXN;;F6W",'<$KG #,#Y&H>G;Z_G*:Y=0W>$0'Y +MWD+9A3$5@!P)2K3B6J (AJD.UGBWFV\,&V_965R#$[CQY39;T@'L_MQ.AT?8KQ:B9Q/-\G&?^;6\:7 +M))\9D(<^:E? AQ6!P+?SI&Q))!AV?)G9';^R2T,MC2[9@N'$W+A (D\.P@KM +MXX=CDRR!?! 'D]V8,[XMPO#Q$WE]/.T-*T2/KX3TB4\+'/FK4)-HV]95P\CK +MT&+R'*$'DBX>#&SRPT>L*ZJ/F=$$ $9>,T==8+V!$_9!#1",_*SHJ&.49XW9 +MNZCMC37*VA2!(%\7B&AAY#]#RE;?&U)>H:"4SV3AIWIJTS7+VEQMVKT4?<=3 +MHMQ0&:K-FE3^8P5.L"75MAQ?8/G*VD$J,<2@ L89IE/1=JA_.5E^L/8,J\B? +MY9\*5&YP@AR*REV^4M?%3_KR(ODP5O G@T4O@@4YPU3O?OD+>JJZ/?O222$4 +M 1KK=VDT^EJ>&C6F:@6)UVJ0 ',J)#%-M4X*M'-2-W01^'8PN\K-T_PD2M)E +MV1!1#S^?@@#AN@742;[T\[IM$"8/;O%VL>./9Z(_Q\ +MV2'SL?EH&V]^@^VIYEVOY*MI"A,IZ_"M)&\WFH)EK\'L)!C;VRRJ-R\7@('I +MK=D)@*-MDV'.]^9U9I42A6[SJO>TD"LK.;\/>M 5LK04"Q4P^[?")_4,6[K! +MCR8CR.HIM@ 9S+Z6.[N@[&+S'WF5_!T)'0^&1[W9F75C__G*+2B!]"WZ#'T.7H8O>%$?IC,DF;(YV-[W:?=TZW +MKX'S4_K5DU&-O;:9_TTAU3+SLNOU6ES^L>:E'\M_$H+S"/HRW(]>.#:B[QL) +MZ4_TQNH)O9K>2 ^D=]#KZ"'T!OJ!6X#E0R^3I\BSZ7'T;OH[?>J=0W^@I]$7 +MZ17T-WHD?: >1H^GE]%/C0[U%?H%_9]>46\Y>M,3ZO7T101(/8C>3W^,;]-7 +MZG7T'W4A3;:L:O0J4!:M[YI%4#$X/-\1[2ZJ%Z#-X4=A[I[C8Y%=-&]9D$'\ +M42634[?,PNQ]1W_TT;EUV]IN"OH>G6M^0Y^G)]0UY5MNF^:NT#^]/L]W.[WH +MT([U6WEF_>HI++13&].SY5W78WDL/6Q^'>534P'TW6A31[4N_5R^+J\L1A-K +MZXT^#+FA7---)\2>S\B!Z=/UF;F=Y$-N4]]Z<]?SZE'T"Y@0]G">5CBI!]+) +MD:;6JY)YD]6:6"^C[[M!Z[5"%WI_/9T:.1:S>VD1['GT82%-?9^^7@]T2]BW +M[!;VZ.R&?:::%@:G3[NIZ\?L!_N*?;_^8B^D\\?[)4[3G1]0? +MZ8/T.OIS?<%^97]VD=CGY"7UG7I _:>>43^H-_I8VX#Q?#6W7%AH%425?]B+ +MZ('VPOC^_$!>.,.W=W_ HD!09-==KG@Y5/:I]H(@K0 +M?-P]?E:ER*R>:PG1!B2S4SV/H4OMJA;I87XAPJN32JQ(PRB%E$D:[M"@EEX_ +M!@! (@#F:DCTIE "B &$9GT0.@ =@ @@#! DK8S=X]GVO @1 +>BR..V/^'" +M[>6;MM7>Y6!'^L9%DZ>'V<2^WEQ+>'>KV &N\7=X^XV#_R7BR +M /KV5BK\N@B "T 'H)W$ ,P J7M2\EDR:0YKF@*$N5&L[8'R>^W^=N_KRMW[ +MCJ3UDWN2@=K>@<2VS]Q#H-_V\$LI\]S^9179&E#]ZW4"KWI+'+O2##>&\PY]PK +M[SWW;0#0_?;ZV:2W-]VC[HE JGO6O>L>=H^_?] 50K#/89WK/>$^9NK!V-[C +MS1/WWOM$=94U?$^'@-RSM*G,BUL'$M@69B &4.#S0MWW:J^)^A<@O< R6-[' +M[YOWH7N\O4.@=(\5R'A"$AJFUVV'D _>]^<,> +,A#XV?O&/0/_UWH6(M_/ +MWB;J$WR*0P6_<4\[:N!K?^-)6J0-OC+'@R^_O]NWCT0 (_R0: E_GL8-@WI) +M,64\0GS!:O,W@O].&>%#5WGX&/QTD :?@T\6(.*#\.?W2/R9A1+_= \#B-VO +ML[;+;QXH/A=_$_B[5[WC\/6VW%4L?O(^@T_%#PE$\;OX\/LB_O/^V93$[]N3 +M\5/W_<3B*D#N)@ 3W48/"_0:?1*>XC^'[U1OX/7P:?IKX57#'CVN5 +MY3WJ H$V=&. @)'0ED/7@WKLM[]7_4D@)4!VWRP+!/[0K0QP%*22T +M(Q%W.O-8_EBV/:AKCE6XHO\CEWP2[3$?-&6+N&?XG)3YS?%I/ET5(%OACN9? +M91_;KLEGOJJK"B")SL[*M8_YP:XA[FN@/+#2QN:W4*;YZ %U]) VG)_+!^<; +M:5U-LVYM8HH.GF\:L/30\]$#Q?RQK#:_*.W/O^?357/=.PQO?H <"<":E W$ +M\S=(I)$_ZC6_::.CG\B/Z,Z%:_C>_HA_SWN;/+K@FY'R%/LG -.O0-PUL +MD*H1C[%+2JOBD@+6\ "$W-/^G7/&3Z*_V)OG=VJ"]K@ND?]57Z-'V-_E@V-% ::.KK +M],-%//W.9D( J)_%OJ)&0-$ KXAD8 =]-#V3(.SL:]T?MZ.Z^O3B.*A3*$=D +M :@ ["$6J%9ZF_UJBC4]\X/D=XLR5'Z&':2D3A#F"((&AH\3=X(5L3[7'U%S +MHV4)N/QM/EG@:<#>47YV11%[A(H$84O@7MPFR(P6]E74NF;T0 (HEQ]SP %4 +MN9!#6Y7ZA;Q$ F&=M^PWHNGZKF@]);W(-*#JJG)I3=?HV(/ 0.[3(?#6N+V; +M]J'1J/T<*GJ@+EGC6%54N6Y$98T,E;\Z9R<3X?K(]4_[AOU6-&=?;?+9+XP] +M243[=Q&E"'&?''K9;["A YWDB(IG/FG$M1^CS@A00C;&N79U A&@*]= #@R( +M*:C[R'W,?FD'M5V4GODP]L' ;_4"85]?7H(42PXQD!>BQWWX@)@BO&_9%D@K +M(3 "U"WT_E76KD_BMSS@]:M<3X*U]NO6_A!?>@ND"D@%W)T)T5[_^?3A?^=# +M$- &S_R1V$L@I^ YMN_0>)U/M_VQ['H_R3\2P\?A^._[@AZ[AF,?K@[9]Q#> +M163\8UG&4_^QQF]Y4#=<^4O[H/WV? +MCII-8@K:/DG"MM_F;Z'H]IT O/V1V)S?)(H'3=YV6%H $ \+"-6GSX\5Y[Y1 +M^7E9@_XG 7$?.N' +Date: 22 Mar 92 00:15:22 GMT +Organization: Rutgers Univ., New Brunswick, N.J. +Lines: 845 + + +The following cdiffs come from Linus. He's had trouble getting +postings out. They are alpha -- only for people who like to test +things. They appear to fix some of the problems with multiple disks, +and some problems with serial lines. I can't be sure about that. +They do fix my problem with gdb getting "bad things happen". +If the posting from Linus shows up, the diffs in that posting +should be identical to these. + +*** OLD/linux/kernel/chr_drv/console.c Fri Mar 13 00:37:07 1992 +--- linux/kernel/chr_drv/console.c Thu Mar 19 21:15:03 1992 +*************** +*** 456,462 **** + p++; + } + sti(); +! copy_to_cooked(tty); + } + + static void insert_char(int currcons) +--- 456,462 ---- + p++; + } + sti(); +! TTY_READ_FLUSH(tty); + } + + static void insert_char(int currcons) +*************** +*** 823,829 **** + + void do_keyboard_interrupt(void) + { +! copy_to_cooked(TTY_TABLE(0)); + timer_active &= ~(1<stopped = 1; +! TTY_WRITE(tty); + return 0; + case TCOON: + tty->stopped = 0; +! TTY_WRITE(tty); + return 0; + case TCIOFF: + if (STOP_CHAR(tty)) +--- 260,270 ---- + switch (arg) { + case TCOOFF: + tty->stopped = 1; +! TTY_WRITE_FLUSH(tty); + return 0; + case TCOON: + tty->stopped = 0; +! TTY_WRITE_FLUSH(tty); + return 0; + case TCIOFF: + if (STOP_CHAR(tty)) +*** OLD/linux/kernel/chr_drv/tty_io.c Tue Mar 17 22:46:46 1992 +--- linux/kernel/chr_drv/tty_io.c Thu Mar 19 21:27:07 1992 +*************** +*** 129,141 **** + printk("copy_to_cooked: missing queues\n\r"); + return; + } +- cli(); +- if (tty->busy) { +- sti(); +- return; +- } +- tty->busy = 1; +- sti(); + while (1) { + if (EMPTY(tty->read_q)) + break; +--- 129,134 ---- +*************** +*** 232,242 **** + PUTCH(c,tty->write_q); + } + PUTCH(c,tty->secondary); + } +- tty->write(tty); +- tty->busy = 0; + if (!EMPTY(tty->secondary)) + wake_up(&tty->secondary->proc_list); + } + + /* +--- 225,236 ---- + PUTCH(c,tty->write_q); + } + PUTCH(c,tty->secondary); ++ TTY_WRITE_FLUSH(tty); + } + if (!EMPTY(tty->secondary)) + wake_up(&tty->secondary->proc_list); ++ if (LEFT(tty->write_q) > TTY_BUF_SIZE/2) ++ wake_up(&tty->write_q->proc_list); + } + + /* +*************** +*** 305,314 **** + time = current->timeout = 0; + if (minimum>nr) + minimum = nr; +! copy_to_cooked(tty); + while (nr>0) { + if (other_tty && other_tty->write) +! TTY_WRITE(other_tty); + cli(); + if (EMPTY(tty->secondary) || (L_CANON(tty) && + !FULL(tty->read_q) && !tty->secondary->data)) { +--- 299,308 ---- + time = current->timeout = 0; + if (minimum>nr) + minimum = nr; +! TTY_READ_FLUSH(tty); + while (nr>0) { + if (other_tty && other_tty->write) +! TTY_WRITE_FLUSH(other_tty); + cli(); + if (EMPTY(tty->secondary) || (L_CANON(tty) && + !FULL(tty->read_q) && !tty->secondary->data)) { +*************** +*** 320,326 **** + break; + interruptible_sleep_on(&tty->secondary->proc_list); + sti(); +! copy_to_cooked(tty); + continue; + } + sti(); +--- 314,320 ---- + break; + interruptible_sleep_on(&tty->secondary->proc_list); + sti(); +! TTY_READ_FLUSH(tty); + continue; + } + sti(); +*************** +*** 398,404 **** + cr_flag = 0; + PUTCH(c,tty->write_q); + } +! TTY_WRITE(tty); + if (nr>0) + schedule(); + } +--- 392,398 ---- + cr_flag = 0; + PUTCH(c,tty->write_q); + } +! TTY_WRITE_FLUSH(tty); + if (nr>0) + schedule(); + } +*** OLD/linux/kernel/chr_drv/serial.c Sat Mar 14 20:16:21 1992 +--- linux/kernel/chr_drv/serial.c Thu Mar 19 21:15:03 1992 +*************** +*** 26,47 **** + + static void com1_timer(void) + { +! copy_to_cooked(tty_table+64); + } + + static void com2_timer(void) + { +! copy_to_cooked(tty_table+65); + } + + static void com3_timer(void) + { +! copy_to_cooked(tty_table+66); + } + + static void com4_timer(void) + { +! copy_to_cooked(tty_table+67); + } + + static inline void do_rs_write(unsigned int port) +--- 26,47 ---- + + static void com1_timer(void) + { +! TTY_READ_FLUSH(tty_table+64); + } + + static void com2_timer(void) + { +! TTY_READ_FLUSH(tty_table+65); + } + + static void com3_timer(void) + { +! TTY_READ_FLUSH(tty_table+66); + } + + static void com4_timer(void) + { +! TTY_READ_FLUSH(tty_table+67); + } + + static inline void do_rs_write(unsigned int port) +*** OLD/linux/kernel/chr_drv/pty.c Sat Jan 11 01:56:45 1992 +--- linux/kernel/chr_drv/pty.c Thu Mar 19 21:15:03 1992 +*************** +*** 25,31 **** + if (FULL(to->read_q)) { + if (FULL(to->secondary)) + break; +! copy_to_cooked(to); + continue; + } + GETCH(from->write_q,c); +--- 25,31 ---- + if (FULL(to->read_q)) { + if (FULL(to->secondary)) + break; +! TTY_READ_FLUSH(to); + continue; + } + GETCH(from->write_q,c); +*************** +*** 33,39 **** + if (current->signal & ~current->blocked) + break; + } +! copy_to_cooked(to); + wake_up(&from->write_q->proc_list); + } + +--- 33,39 ---- + if (current->signal & ~current->blocked) + break; + } +! TTY_READ_FLUSH(to); + wake_up(&from->write_q->proc_list); + } + +*** OLD/linux/kernel/blk_drv/hd.c Sun Mar 15 20:46:53 1992 +--- linux/kernel/blk_drv/hd.c Fri Mar 20 00:20:49 1992 +*************** +*** 82,88 **** +--- 82,90 ---- + int minor, i; + struct buffer_head *bh; + struct partition *p; ++ unsigned long first_sector; + ++ first_sector = hd[MINOR(dev)].start_sect; + if (!(bh = bread(dev,0))) { + printk("Unable to read partition table of device %04x\n",dev); + return; +*************** +*** 93,99 **** + for (i=0 ; i<4 ; i++,p++) { + if (!(hd[i+minor].nr_sects = p->nr_sects)) + continue; +! hd[i+minor].start_sect = p->start_sect; + if ((current_minor & 0x3f) >= 60) + continue; + if (p->sys_ind == EXTENDED_PARTITION) { +--- 95,101 ---- + for (i=0 ; i<4 ; i++,p++) { + if (!(hd[i+minor].nr_sects = p->nr_sects)) + continue; +! hd[i+minor].start_sect = first_sector + p->start_sect; + if ((current_minor & 0x3f) >= 60) + continue; + if (p->sys_ind == EXTENDED_PARTITION) { +*************** +*** 141,156 **** + hd_info[drive].sect = *(unsigned char *) (14+BIOS); + BIOS += 16; + } +- if (hd_info[1].cyl) +- NR_HD=2; +- else +- NR_HD=1; +- #endif +- for (i=0 ; itss.esp0; + stack += offset; +! *(int *) stack = data; + return 0; + } + + /* +! * this routine will get a word out of an arbitrary +! * tasks data space. It likes to have the task number +! * rather than the task pointer. Perhaps the number +! * should be included in the pointer. + */ +! /* seg = 0 if I space */ +! static inline int get_long(int tsk, long addr, unsigned seg, int *data) + { +- int i; +- int limit; +- int cur; +- unsigned long address; + unsigned long page; +- unsigned oldfs; + +! /* find the task number of the current task. */ +! for (i = 0; i < NR_TASKS ; i ++) { +! if (task[i] == current) break; + } +- if (i == NR_TASKS) { +- printk("PTRACE: Can't find current task\n"); +- do_exit(SIGSEGV); +- } +- cur = i; +- +- /* we will need to check the readability of the segment +- and then the byte in order to avoid segment violations. */ +- seg++; +- limit = (task[tsk]->ldt[seg].a) & 0xffff; +- /* this should be constant amound all of our segments, but we +- had better check anyway. */ +- if (task[tsk]->ldt[seg].b & GRANULARITY) +- limit = limit << 12; +- +- if (limit <= addr+4) +- return -EIO; +- +- /* Now compute the address, and make sure that it is present. */ +- address = task[tsk]->start_code + addr; +- +- page = *((unsigned long*) ((address >> 20) & 0xffc)); +- /* see if it is present. */ + if (!(page & PAGE_PRESENT)) { +! do_no_page(0, address, task[tsk]); + } +! +! oldfs = get_fs(); +! /* now convert seg to the right format. */ +! seg = (seg << 3) | 0x4; +! +! cli(); /* we are about to change our ldt, we better do it +! with interrupts off. Perhaps we should call schedule +! first so that we won't be taking too much extra time. */ +! lldt(tsk); +! set_fs(seg); +! *data = get_fs_long((void *)addr); /* we are assuming kernel space +! is in the gdt here. */ +! lldt(cur); +! set_fs(oldfs); +! sti(); +! return 0; + } + + /* +! * this routine will get a word out of an arbitrary +! * tasks data space. It likes to have the task number +! * rather than the task pointer. Perhaps the number +! * should be included in the pointer. + */ +! /* seg = 0 if I space */ +! static inline int put_long(int tsk, long addr, int data, unsigned seg) + { +- int i; +- int limit; +- unsigned oldfs; +- unsigned long address; + unsigned long page; +- int cur; + +! /* find the task number of the current task. */ +! for (i = 0; i < NR_TASKS ; i++) { +! if (task[i] == current) break; + } +! if (i == NR_TASKS) { +! printk("PTRACE: Can't find current task\n"); +! do_exit(SIGSEGV); + } +! cur = i; + +! /* we will need to check the readability of the segment +! and then the byte in order to avoid segment violations. */ +! seg++; +! limit = (task[tsk]->ldt[seg].a) & 0xffff; +! /* this should be constant amound all of our segments, but we +! had better check anyway. */ +! if (task[tsk]->ldt[seg].b & GRANULARITY) +! limit = limit << 12; + +! if (limit <= addr+4) + return -EIO; + +! /* Now compute the address, and make sure that it is present. */ +! address = task[tsk]->start_code + addr; + +! page = *((unsigned long*) ((address >> 20) & 0xffc)); +! /* see if it is present. */ +! if (!(page & PAGE_PRESENT)) { +! do_no_page(0, address, task[tsk]); +! } +! write_verify(address); +! +! oldfs=get_fs(); +! /* now convert seg to the right format. */ +! seg = (seg << 3) | 0x4; +! +! cli(); /* we are about to change our ldt, we better do it +! with interrupts off. Perhaps we should call schedule +! first so that we won't be taking too much extra time. */ +! lldt(tsk); +! set_fs(seg); +! put_fs_long(data,(void *)addr); +! lldt(cur); +! set_fs(oldfs); +! sti(); + return 0; + } + +- + /* Perform ptrace(request, pid, addr, data) syscall */ + int sys_ptrace(unsigned long *buffer) + { +--- 65,223 ---- + * data space. + */ + static inline int put_stack_long(struct task_struct *task, int offset, +! unsigned long data) + { + unsigned char * stack; + + stack = (unsigned char *) task->tss.esp0; + stack += offset; +! *(unsigned long *) stack = data; + return 0; + } + + /* +! * This routine gets a long from any process space by following the page +! * tables. NOTE! You should check that the long isn't on a page boundary, +! * and that it is in the task area before calling this: this routine does +! * no checking. +! * +! * NOTE2! This uses "tsk->tss.cr3" even though we know it's currently always +! * zero. This routine shouldn't have to change when we make a better mm. + */ +! static unsigned long get_long(struct task_struct * tsk, +! unsigned long addr) + { + unsigned long page; + +! addr += tsk->start_code; +! repeat: +! page = tsk->tss.cr3 + ((addr >> 20) & 0xffc); +! page = *(unsigned long *) page; +! if (page & PAGE_PRESENT) { +! page &= 0xfffff000; +! page += (addr >> 10) & 0xffc; +! page = *((unsigned long *) page); + } + if (!(page & PAGE_PRESENT)) { +! do_no_page(0,addr,tsk); +! goto repeat; + } +! page &= 0xfffff000; +! page += addr & 0xfff; +! return *(unsigned long *) page; + } + + /* +! * This routine puts a long into any process space by following the page +! * tables. NOTE! You should check that the long isn't on a page boundary, +! * and that it is in the task area before calling this: this routine does +! * no checking. + */ +! static void put_long(struct task_struct * tsk, unsigned long addr, +! unsigned long data) + { + unsigned long page; + +! addr += tsk->start_code; +! repeat: +! page = tsk->tss.cr3 + ((addr >> 20) & 0xffc); +! page = *(unsigned long *) page; +! if (page & PAGE_PRESENT) { +! page &= 0xfffff000; +! page += (addr >> 10) & 0xffc; +! page = *((unsigned long *) page); + } +! if (!(page & PAGE_PRESENT)) { +! do_no_page(0,addr,tsk); +! goto repeat; + } +! if (!(page & PAGE_RW)) { +! write_verify(addr); +! goto repeat; +! } +! page &= 0xfffff000; +! page += addr & 0xfff; +! *(unsigned long *) page = data; +! } + +! /* +! * This routine checks the page boundaries, and that the offset is +! * within the task area. It then calls get_long() to read a long. +! */ +! static int read_long(struct task_struct * tsk, unsigned long addr, +! unsigned long * result) +! { +! unsigned long low,high; + +! if (addr > TASK_SIZE-4) + return -EIO; ++ if ((addr & 0xfff) > PAGE_SIZE-4) { ++ low = get_long(tsk,addr & 0xfffffffc); ++ high = get_long(tsk,(addr+4) & 0xfffffffc); ++ switch (addr & 3) { ++ case 1: ++ low >>= 8; ++ low |= high << 24; ++ break; ++ case 2: ++ low >>= 16; ++ low |= high << 16; ++ break; ++ case 3: ++ low >>= 16; ++ low |= high << 16; ++ break; ++ } ++ *result = low; ++ } else ++ *result = get_long(tsk,addr); ++ return 0; ++ } + +! /* +! * This routine checks the page boundaries, and that the offset is +! * within the task area. It then calls put_long() to write a long. +! */ +! static int write_long(struct task_struct * tsk, unsigned long addr, +! unsigned long data) +! { +! unsigned long low,high; + +! if (addr > TASK_SIZE-4) +! return -EIO; +! if ((addr & 0xfff) > PAGE_SIZE-4) { +! low = get_long(tsk,addr & 0xfffffffc); +! high = get_long(tsk,(addr+4) & 0xfffffffc); +! switch (addr & 3) { +! case 0: /* shouldn't happen, but safety first */ +! low = data; +! break; +! case 1: +! low &= 0x000000ff; +! low |= data << 8; +! high &= 0xff000000; +! high |= data >> 8; +! break; +! case 2: +! low &= 0x0000ffff; +! low |= data << 16; +! high &= 0xffff0000; +! high |= data >> 16; +! break; +! case 3: +! low &= 0x00ffffff; +! low |= data << 24; +! high &= 0xffffff00; +! high |= data >> 24; +! break; +! } +! put_long(tsk,addr & 0xfffffffc,low); +! put_long(tsk,(addr+4) & 0xfffffffc,high); +! } else +! put_long(tsk,addr,data); + return 0; + } + + /* Perform ptrace(request, pid, addr, data) syscall */ + int sys_ptrace(unsigned long *buffer) + { +*************** +*** 244,250 **** + case 2: { + int tmp,res; + +! res = get_long(childno, addr, 1, &tmp); + if (res < 0) + return res; + verify_area((void *) data, 4); +--- 254,260 ---- + case 2: { + int tmp,res; + +! res = read_long(task[childno], addr, &tmp); + if (res < 0) + return res; + verify_area((void *) data, 4); +*************** +*** 267,280 **** + /* when I and D space are seperate, this will have to be fixed. */ + case 4: /* write the word at location addr. */ + case 5: +! if (put_long(childno, addr, data, 1)) +! return -EIO; +! return 0; + + case 6: /* write the word at location addr in the USER area */ + addr = addr >> 2; /* temproary hack. */ + if (addr < 0 || addr >= 17) +! return -EIO; + if (addr == ORIG_EAX) + return -EIO; + if (addr == EFL) { /* flags. */ +--- 277,288 ---- + /* when I and D space are seperate, this will have to be fixed. */ + case 4: /* write the word at location addr. */ + case 5: +! return write_long(task[childno],addr,data); + + case 6: /* write the word at location addr in the USER area */ + addr = addr >> 2; /* temproary hack. */ + if (addr < 0 || addr >= 17) +! return -EIO; + if (addr == ORIG_EAX) + return -EIO; + if (addr == EFL) { /* flags. */ +*************** +*** 281,287 **** + data &= FLAG_MASK; + data |= get_stack_long(child, EFL*4-MAGICNUMBER) & ~FLAG_MASK; + } +- + if (put_stack_long(child, 4*addr-MAGICNUMBER, data)) + return -EIO; + return 0; +--- 289,294 ---- +*** OLD/linux/mm/memory.c Tue Mar 17 22:35:13 1992 +--- linux/mm/memory.c Thu Mar 19 23:19:03 1992 +*************** +*** 429,436 **** + return 0; + } + +! void do_no_page(unsigned long error_code, +! unsigned long address, struct task_struct *tsk) + { + static unsigned int last_checked = 0; + int nr[4]; +--- 429,436 ---- + return 0; + } + +! void do_no_page(unsigned long error_code, unsigned long address, +! struct task_struct *tsk) + { + static unsigned int last_checked = 0; + int nr[4]; +*************** +*** 439,445 **** + int block,i; + struct inode * inode; + +! /* Trashing ? Make it interruptible, but don't penalize otherwise */ + for (i = 0; i < CHECK_LAST_NR; i++) + if ((address & 0xfffff000) == last_pages[i]) { + current->counter = 0; +--- 439,445 ---- + int block,i; + struct inode * inode; + +! /* Thrashing ? Make it interruptible, but don't penalize otherwise */ + for (i = 0; i < CHECK_LAST_NR; i++) + if ((address & 0xfffff000) == last_pages[i]) { + current->counter = 0; +*************** +*** 492,499 **** + return; + } + if (tsk == current) +! if (share_page(inode,tmp)) +! return; + if (!(page = get_free_page())) + oom(); + /* remember that 1 block is used for header */ +--- 492,499 ---- + return; + } + if (tsk == current) +! if (share_page(inode,tmp)) +! return; + if (!(page = get_free_page())) + oom(); + /* remember that 1 block is used for header */ +*** OLD/linux/include/linux/tty.h Sun Mar 15 02:43:54 1992 +--- linux/include/linux/tty.h Thu Mar 19 21:16:26 1992 +*************** +*** 68,83 **** + struct tty_queue *secondary; + }; + +! #define TTY_WRITE(tty) \ + do { \ + cli(); \ +! if (!(tty)->busy) { \ +! (tty)->busy = 1; \ + sti(); \ + (tty)->write((tty)); \ +! (tty)->busy = 0; \ +! } else \ + sti(); \ + } while (0) + + extern struct tty_struct tty_table[]; +--- 68,105 ---- + struct tty_queue *secondary; + }; + +! /* +! * so that interrupts won't be able to mess up the +! * queues, copy_to_cooked must be atomic with repect +! * to itself, as must tty->write. +! */ +! #define TTY_WRITE_BUSY 1 +! #define TTY_READ_BUSY 2 +! +! #define TTY_WRITE_FLUSH(tty) \ + do { \ + cli(); \ +! if (!EMPTY((tty)->write_q) && !(TTY_WRITE_BUSY & (tty)->busy)) { \ +! (tty)->busy |= TTY_WRITE_BUSY; \ + sti(); \ + (tty)->write((tty)); \ +! cli(); \ +! (tty)->busy &= ~TTY_WRITE_BUSY; \ +! } \ +! sti(); \ +! } while (0) +! +! #define TTY_READ_FLUSH(tty) \ +! do { \ +! cli(); \ +! if (!EMPTY((tty)->read_q) && !(TTY_READ_BUSY & (tty)->busy)) { \ +! (tty)->busy |= TTY_READ_BUSY; \ + sti(); \ ++ copy_to_cooked((tty)); \ ++ cli(); \ ++ (tty)->busy &= ~TTY_READ_BUSY; \ ++ } \ ++ sti(); \ + } while (0) + + extern struct tty_struct tty_table[]; + + diff --git a/Linux-0.95/patchs/config95a.tar.Z b/Linux-0.95/patchs/config95a.tar.Z new file mode 100644 index 00000000..b52d6bb6 Binary files /dev/null and b/Linux-0.95/patchs/config95a.tar.Z differ diff --git a/Linux-0.95/patchs/configc+.tar.Z b/Linux-0.95/patchs/configc+.tar.Z new file mode 100644 index 00000000..a8098df9 Binary files /dev/null and b/Linux-0.95/patchs/configc+.tar.Z differ diff --git a/Linux-0.95/patchs/dvorak.patch b/Linux-0.95/patchs/dvorak.patch new file mode 100644 index 00000000..a1316cee --- /dev/null +++ b/Linux-0.95/patchs/dvorak.patch @@ -0,0 +1,114 @@ +From: mper@uipsuxb.ps.uiuc.edu (Michael Pereckas) + +This patch for linux/kernel/chr_drv/keyboard.S does two things: it +causes the ./del key on the keypad to produce a period, instead of a +comma, and it adds a Dvorak keyboard. + +The first change will probably appeal to US users. Others may prefer +the comma. If there is a lot of difference of opinion on this, maybe +num_table should be moved into the national keyboard definitions. The +second change is great if you, like me, like the Dvorak keyboard +layout. Unfortunatly, the only way to change keyboards is to reboot +with a different kernel, so the Dvorak keyboard is a problem is more +than one person use the machine and they don't all know Dvorak. (this +only effects the console, serial port connections are uneffected.) + +I post this on the off chance that someone is interested. If you +choose to use this, remember that although it seems to work fine for +me, this is an example of "programming by meta-w", that is, I copied +the US keyboard definition (using the emacs command meta-w) and +modified it, without really understanding it. + + +This patch is for linux/kernel/chr_drv/keyboard.S +It works for all the 0.95* versions, I think (!) +********** CUT HERE ********** +*** keyboard.S.ori Wed Apr 8 16:57:58 1992 +--- keyboard.S Wed Apr 8 17:03:10 1992 +*************** +*** 18,23 **** +--- 18,24 ---- + * KBD_FR for Frech keyboard + * KBD_UK for British extended keyboard + * KBD_DK for Danish keyboard ++ * KBD_DVORAK for Dvorak (US) keyboard + */ + + .text +*************** +*** 251,257 **** + .ascii "789-456+1230." + #else + num_table: +! .ascii "789-456+1230," + #endif + cur_table: + .ascii "HA5-DGC+YB623" +--- 252,258 ---- + .ascii "789-456+1230." + #else + num_table: +! .ascii "789-456+1230." + #endif + cur_table: + .ascii "HA5-DGC+YB623" +*************** +*** 611,616 **** +--- 612,667 ---- + .byte 0,0,0,0,0 /* 4A-4E */ + .byte 0,0,0,0,0,0,0 /* 4F-55 */ + .ascii "\\" ++ .fill 10,1,0 ++ ++ #elif defined(KBD_DVORAK) ++ ++ key_map: ++ .byte 0,27 ++ .ascii "1234567890\\=" ++ .byte 127,9 ++ .ascii "',.pyfgcrl/]" ++ .byte 13,0 ++ .ascii "aoeuidhtns-" ++ .byte '`,0 ++ .ascii "[;qjkxbmwvz" ++ .byte 0,'*,0,32 /* 36-39 */ ++ .fill 16,1,0 /* 3A-49 */ ++ .byte '-,0,0,0,'+ /* 4A-4E */ ++ .byte 0,0,0,0,0,0,0 /* 4F-55 */ ++ .byte '< ++ .fill 10,1,0 ++ ++ shift_map: ++ .byte 0,27 ++ .ascii "!@#$%^&*()|+" ++ .byte 127,9 ++ .ascii "\"<>PYFGCRL?}" ++ .byte 13,0 ++ .ascii "AOEUIDHTNS_" ++ .byte '~,0 ++ .ascii "{:QJKXBMWVZ" ++ .byte 0,'*,0,32 /* 36-39 */ ++ .fill 16,1,0 /* 3A-49 */ ++ .byte '-,0,0,0,'+ /* 4A-4E */ ++ .byte 0,0,0,0,0,0,0 /* 4F-55 */ ++ .byte '> ++ .fill 10,1,0 ++ ++ alt_map: ++ .byte 0,0 ++ .ascii "\0@\0$\0\0{[]}\\\0" ++ .byte 0,0 ++ .byte 0,0,0,0,0,0,0,0,0,0,0 ++ .byte '~,13,0 ++ .byte 0,0,0,0,0,0,0,0,0,0,0 ++ .byte 0,0 ++ .byte 0,0,0,0,0,0,0,0,0,0,0 ++ .byte 0,0,0,0 /* 36-39 */ ++ .fill 16,1,0 /* 3A-49 */ ++ .byte 0,0,0,0,0 /* 4A-4E */ ++ .byte 0,0,0,0,0,0,0 /* 4F-55 */ ++ .byte '| + .fill 10,1,0 + + #else + diff --git a/Linux-0.95/patchs/keyboard_rate.patch b/Linux-0.95/patchs/keyboard_rate.patch new file mode 100644 index 00000000..3d111941 --- /dev/null +++ b/Linux-0.95/patchs/keyboard_rate.patch @@ -0,0 +1,34 @@ +From: johnsonm@stolaf.edu (Michael K. Johnson) +Subject: changing keyboard repeat rate. + +OK, I have gotten several requests for info on how to change the +keyboard repeat rate, so here goes. Note: I can't just give diffs, +because there are lots of options, and for heaven's sake it's only +three lines of code. + +In boot/setup.S, there are the lines: + +! set the keyboard repeat rate to the max + + mov ax,#0x0305 + mov bx,0x0000 + int 0x16 + +If you don't want to change the repeat rate at all, just comment out +these lines by prefacing them with !'s. If you want something in the +middle, change the + mov bx,0x0000 +to mov bx,0x???? +where ???? is determined by (from Ralf Brown's interrupt list) +bh = delay value (0x00 = 250 ms to 0x03 = 1000 ms (one second)) + this is the delay before the repeat starts happening +bl = repeat rate (0x00 = 30/sec to 0x0c = 10/sec [default] to 0x1f = 2/sec) + +I use mov bx,0x0006 +to delay 1/4 sec, then repeat at what I think is a comfortable rate. +I am too lazy to calculate the exact speed -- maybe 20/sec? ;-) + +Hope this helps people. + +michaelkjohnson +johnsonm@stolaf.edu diff --git a/Linux-0.95/patchs/linus-95a-patch b/Linux-0.95/patchs/linus-95a-patch new file mode 100644 index 00000000..48bd025c --- /dev/null +++ b/Linux-0.95/patchs/linus-95a-patch @@ -0,0 +1,837 @@ +*** OLD/linux/kernel/chr_drv/console.c Fri Mar 13 00:37:07 1992 +--- linux/kernel/chr_drv/console.c Thu Mar 19 21:15:03 1992 +*************** +*** 456,462 **** + p++; + } + sti(); +! copy_to_cooked(tty); + } + + static void insert_char(int currcons) +--- 456,462 ---- + p++; + } + sti(); +! TTY_READ_FLUSH(tty); + } + + static void insert_char(int currcons) +*************** +*** 823,829 **** + + void do_keyboard_interrupt(void) + { +! copy_to_cooked(TTY_TABLE(0)); + timer_active &= ~(1<stopped = 1; +! TTY_WRITE(tty); + return 0; + case TCOON: + tty->stopped = 0; +! TTY_WRITE(tty); + return 0; + case TCIOFF: + if (STOP_CHAR(tty)) +--- 260,270 ---- + switch (arg) { + case TCOOFF: + tty->stopped = 1; +! TTY_WRITE_FLUSH(tty); + return 0; + case TCOON: + tty->stopped = 0; +! TTY_WRITE_FLUSH(tty); + return 0; + case TCIOFF: + if (STOP_CHAR(tty)) +*** OLD/linux/kernel/chr_drv/tty_io.c Tue Mar 17 22:46:46 1992 +--- linux/kernel/chr_drv/tty_io.c Thu Mar 19 21:27:07 1992 +*************** +*** 129,141 **** + printk("copy_to_cooked: missing queues\n\r"); + return; + } +- cli(); +- if (tty->busy) { +- sti(); +- return; +- } +- tty->busy = 1; +- sti(); + while (1) { + if (EMPTY(tty->read_q)) + break; +--- 129,134 ---- +*************** +*** 232,242 **** + PUTCH(c,tty->write_q); + } + PUTCH(c,tty->secondary); + } +- tty->write(tty); +- tty->busy = 0; + if (!EMPTY(tty->secondary)) + wake_up(&tty->secondary->proc_list); + } + + /* +--- 225,236 ---- + PUTCH(c,tty->write_q); + } + PUTCH(c,tty->secondary); ++ TTY_WRITE_FLUSH(tty); + } + if (!EMPTY(tty->secondary)) + wake_up(&tty->secondary->proc_list); ++ if (LEFT(tty->write_q) > TTY_BUF_SIZE/2) ++ wake_up(&tty->write_q->proc_list); + } + + /* +*************** +*** 305,314 **** + time = current->timeout = 0; + if (minimum>nr) + minimum = nr; +! copy_to_cooked(tty); + while (nr>0) { + if (other_tty && other_tty->write) +! TTY_WRITE(other_tty); + cli(); + if (EMPTY(tty->secondary) || (L_CANON(tty) && + !FULL(tty->read_q) && !tty->secondary->data)) { +--- 299,308 ---- + time = current->timeout = 0; + if (minimum>nr) + minimum = nr; +! TTY_READ_FLUSH(tty); + while (nr>0) { + if (other_tty && other_tty->write) +! TTY_WRITE_FLUSH(other_tty); + cli(); + if (EMPTY(tty->secondary) || (L_CANON(tty) && + !FULL(tty->read_q) && !tty->secondary->data)) { +*************** +*** 320,326 **** + break; + interruptible_sleep_on(&tty->secondary->proc_list); + sti(); +! copy_to_cooked(tty); + continue; + } + sti(); +--- 314,320 ---- + break; + interruptible_sleep_on(&tty->secondary->proc_list); + sti(); +! TTY_READ_FLUSH(tty); + continue; + } + sti(); +*************** +*** 398,404 **** + cr_flag = 0; + PUTCH(c,tty->write_q); + } +! TTY_WRITE(tty); + if (nr>0) + schedule(); + } +--- 392,398 ---- + cr_flag = 0; + PUTCH(c,tty->write_q); + } +! TTY_WRITE_FLUSH(tty); + if (nr>0) + schedule(); + } +*** OLD/linux/kernel/chr_drv/serial.c Sat Mar 14 20:16:21 1992 +--- linux/kernel/chr_drv/serial.c Thu Mar 19 21:15:03 1992 +*************** +*** 26,47 **** + + static void com1_timer(void) + { +! copy_to_cooked(tty_table+64); + } + + static void com2_timer(void) + { +! copy_to_cooked(tty_table+65); + } + + static void com3_timer(void) + { +! copy_to_cooked(tty_table+66); + } + + static void com4_timer(void) + { +! copy_to_cooked(tty_table+67); + } + + static inline void do_rs_write(unsigned int port) +--- 26,47 ---- + + static void com1_timer(void) + { +! TTY_READ_FLUSH(tty_table+64); + } + + static void com2_timer(void) + { +! TTY_READ_FLUSH(tty_table+65); + } + + static void com3_timer(void) + { +! TTY_READ_FLUSH(tty_table+66); + } + + static void com4_timer(void) + { +! TTY_READ_FLUSH(tty_table+67); + } + + static inline void do_rs_write(unsigned int port) +*** OLD/linux/kernel/chr_drv/pty.c Sat Jan 11 01:56:45 1992 +--- linux/kernel/chr_drv/pty.c Thu Mar 19 21:15:03 1992 +*************** +*** 25,31 **** + if (FULL(to->read_q)) { + if (FULL(to->secondary)) + break; +! copy_to_cooked(to); + continue; + } + GETCH(from->write_q,c); +--- 25,31 ---- + if (FULL(to->read_q)) { + if (FULL(to->secondary)) + break; +! TTY_READ_FLUSH(to); + continue; + } + GETCH(from->write_q,c); +*************** +*** 33,39 **** + if (current->signal & ~current->blocked) + break; + } +! copy_to_cooked(to); + wake_up(&from->write_q->proc_list); + } + +--- 33,39 ---- + if (current->signal & ~current->blocked) + break; + } +! TTY_READ_FLUSH(to); + wake_up(&from->write_q->proc_list); + } + +*** OLD/linux/kernel/blk_drv/hd.c Sun Mar 15 20:46:53 1992 +--- linux/kernel/blk_drv/hd.c Fri Mar 20 00:20:49 1992 +*************** +*** 82,88 **** +--- 82,90 ---- + int minor, i; + struct buffer_head *bh; + struct partition *p; ++ unsigned long first_sector; + ++ first_sector = hd[MINOR(dev)].start_sect; + if (!(bh = bread(dev,0))) { + printk("Unable to read partition table of device %04x\n",dev); + return; +*************** +*** 93,99 **** + for (i=0 ; i<4 ; i++,p++) { + if (!(hd[i+minor].nr_sects = p->nr_sects)) + continue; +! hd[i+minor].start_sect = p->start_sect; + if ((current_minor & 0x3f) >= 60) + continue; + if (p->sys_ind == EXTENDED_PARTITION) { +--- 95,101 ---- + for (i=0 ; i<4 ; i++,p++) { + if (!(hd[i+minor].nr_sects = p->nr_sects)) + continue; +! hd[i+minor].start_sect = first_sector + p->start_sect; + if ((current_minor & 0x3f) >= 60) + continue; + if (p->sys_ind == EXTENDED_PARTITION) { +*************** +*** 141,156 **** + hd_info[drive].sect = *(unsigned char *) (14+BIOS); + BIOS += 16; + } +- if (hd_info[1].cyl) +- NR_HD=2; +- else +- NR_HD=1; +- #endif +- for (i=0 ; itss.esp0; + stack += offset; +! *(int *) stack = data; + return 0; + } + + /* +! * this routine will get a word out of an arbitrary +! * tasks data space. It likes to have the task number +! * rather than the task pointer. Perhaps the number +! * should be included in the pointer. + */ +! /* seg = 0 if I space */ +! static inline int get_long(int tsk, long addr, unsigned seg, int *data) + { +- int i; +- int limit; +- int cur; +- unsigned long address; + unsigned long page; +- unsigned oldfs; + +! /* find the task number of the current task. */ +! for (i = 0; i < NR_TASKS ; i ++) { +! if (task[i] == current) break; + } +- if (i == NR_TASKS) { +- printk("PTRACE: Can't find current task\n"); +- do_exit(SIGSEGV); +- } +- cur = i; +- +- /* we will need to check the readability of the segment +- and then the byte in order to avoid segment violations. */ +- seg++; +- limit = (task[tsk]->ldt[seg].a) & 0xffff; +- /* this should be constant amound all of our segments, but we +- had better check anyway. */ +- if (task[tsk]->ldt[seg].b & GRANULARITY) +- limit = limit << 12; +- +- if (limit <= addr+4) +- return -EIO; +- +- /* Now compute the address, and make sure that it is present. */ +- address = task[tsk]->start_code + addr; +- +- page = *((unsigned long*) ((address >> 20) & 0xffc)); +- /* see if it is present. */ + if (!(page & PAGE_PRESENT)) { +! do_no_page(0, address, task[tsk]); + } +! +! oldfs = get_fs(); +! /* now convert seg to the right format. */ +! seg = (seg << 3) | 0x4; +! +! cli(); /* we are about to change our ldt, we better do it +! with interrupts off. Perhaps we should call schedule +! first so that we won't be taking too much extra time. */ +! lldt(tsk); +! set_fs(seg); +! *data = get_fs_long((void *)addr); /* we are assuming kernel space +! is in the gdt here. */ +! lldt(cur); +! set_fs(oldfs); +! sti(); +! return 0; + } + + /* +! * this routine will get a word out of an arbitrary +! * tasks data space. It likes to have the task number +! * rather than the task pointer. Perhaps the number +! * should be included in the pointer. + */ +! /* seg = 0 if I space */ +! static inline int put_long(int tsk, long addr, int data, unsigned seg) + { +- int i; +- int limit; +- unsigned oldfs; +- unsigned long address; + unsigned long page; +- int cur; + +! /* find the task number of the current task. */ +! for (i = 0; i < NR_TASKS ; i++) { +! if (task[i] == current) break; + } +! if (i == NR_TASKS) { +! printk("PTRACE: Can't find current task\n"); +! do_exit(SIGSEGV); + } +! cur = i; + +! /* we will need to check the readability of the segment +! and then the byte in order to avoid segment violations. */ +! seg++; +! limit = (task[tsk]->ldt[seg].a) & 0xffff; +! /* this should be constant amound all of our segments, but we +! had better check anyway. */ +! if (task[tsk]->ldt[seg].b & GRANULARITY) +! limit = limit << 12; + +! if (limit <= addr+4) + return -EIO; + +! /* Now compute the address, and make sure that it is present. */ +! address = task[tsk]->start_code + addr; + +! page = *((unsigned long*) ((address >> 20) & 0xffc)); +! /* see if it is present. */ +! if (!(page & PAGE_PRESENT)) { +! do_no_page(0, address, task[tsk]); +! } +! write_verify(address); +! +! oldfs=get_fs(); +! /* now convert seg to the right format. */ +! seg = (seg << 3) | 0x4; +! +! cli(); /* we are about to change our ldt, we better do it +! with interrupts off. Perhaps we should call schedule +! first so that we won't be taking too much extra time. */ +! lldt(tsk); +! set_fs(seg); +! put_fs_long(data,(void *)addr); +! lldt(cur); +! set_fs(oldfs); +! sti(); + return 0; + } + +- + /* Perform ptrace(request, pid, addr, data) syscall */ + int sys_ptrace(unsigned long *buffer) + { +--- 65,223 ---- + * data space. + */ + static inline int put_stack_long(struct task_struct *task, int offset, +! unsigned long data) + { + unsigned char * stack; + + stack = (unsigned char *) task->tss.esp0; + stack += offset; +! *(unsigned long *) stack = data; + return 0; + } + + /* +! * This routine gets a long from any process space by following the page +! * tables. NOTE! You should check that the long isn't on a page boundary, +! * and that it is in the task area before calling this: this routine does +! * no checking. +! * +! * NOTE2! This uses "tsk->tss.cr3" even though we know it's currently always +! * zero. This routine shouldn't have to change when we make a better mm. + */ +! static unsigned long get_long(struct task_struct * tsk, +! unsigned long addr) + { + unsigned long page; + +! addr += tsk->start_code; +! repeat: +! page = tsk->tss.cr3 + ((addr >> 20) & 0xffc); +! page = *(unsigned long *) page; +! if (page & PAGE_PRESENT) { +! page &= 0xfffff000; +! page += (addr >> 10) & 0xffc; +! page = *((unsigned long *) page); + } + if (!(page & PAGE_PRESENT)) { +! do_no_page(0,addr,tsk); +! goto repeat; + } +! page &= 0xfffff000; +! page += addr & 0xfff; +! return *(unsigned long *) page; + } + + /* +! * This routine puts a long into any process space by following the page +! * tables. NOTE! You should check that the long isn't on a page boundary, +! * and that it is in the task area before calling this: this routine does +! * no checking. + */ +! static void put_long(struct task_struct * tsk, unsigned long addr, +! unsigned long data) + { + unsigned long page; + +! addr += tsk->start_code; +! repeat: +! page = tsk->tss.cr3 + ((addr >> 20) & 0xffc); +! page = *(unsigned long *) page; +! if (page & PAGE_PRESENT) { +! page &= 0xfffff000; +! page += (addr >> 10) & 0xffc; +! page = *((unsigned long *) page); + } +! if (!(page & PAGE_PRESENT)) { +! do_no_page(0,addr,tsk); +! goto repeat; + } +! if (!(page & PAGE_RW)) { +! write_verify(addr); +! goto repeat; +! } +! page &= 0xfffff000; +! page += addr & 0xfff; +! *(unsigned long *) page = data; +! } + +! /* +! * This routine checks the page boundaries, and that the offset is +! * within the task area. It then calls get_long() to read a long. +! */ +! static int read_long(struct task_struct * tsk, unsigned long addr, +! unsigned long * result) +! { +! unsigned long low,high; + +! if (addr > TASK_SIZE-4) + return -EIO; ++ if ((addr & 0xfff) > PAGE_SIZE-4) { ++ low = get_long(tsk,addr & 0xfffffffc); ++ high = get_long(tsk,(addr+4) & 0xfffffffc); ++ switch (addr & 3) { ++ case 1: ++ low >>= 8; ++ low |= high << 24; ++ break; ++ case 2: ++ low >>= 16; ++ low |= high << 16; ++ break; ++ case 3: ++ low >>= 16; ++ low |= high << 16; ++ break; ++ } ++ *result = low; ++ } else ++ *result = get_long(tsk,addr); ++ return 0; ++ } + +! /* +! * This routine checks the page boundaries, and that the offset is +! * within the task area. It then calls put_long() to write a long. +! */ +! static int write_long(struct task_struct * tsk, unsigned long addr, +! unsigned long data) +! { +! unsigned long low,high; + +! if (addr > TASK_SIZE-4) +! return -EIO; +! if ((addr & 0xfff) > PAGE_SIZE-4) { +! low = get_long(tsk,addr & 0xfffffffc); +! high = get_long(tsk,(addr+4) & 0xfffffffc); +! switch (addr & 3) { +! case 0: /* shouldn't happen, but safety first */ +! low = data; +! break; +! case 1: +! low &= 0x000000ff; +! low |= data << 8; +! high &= 0xff000000; +! high |= data >> 8; +! break; +! case 2: +! low &= 0x0000ffff; +! low |= data << 16; +! high &= 0xffff0000; +! high |= data >> 16; +! break; +! case 3: +! low &= 0x00ffffff; +! low |= data << 24; +! high &= 0xffffff00; +! high |= data >> 24; +! break; +! } +! put_long(tsk,addr & 0xfffffffc,low); +! put_long(tsk,(addr+4) & 0xfffffffc,high); +! } else +! put_long(tsk,addr,data); + return 0; + } + + /* Perform ptrace(request, pid, addr, data) syscall */ + int sys_ptrace(unsigned long *buffer) + { +*************** +*** 244,250 **** + case 2: { + int tmp,res; + +! res = get_long(childno, addr, 1, &tmp); + if (res < 0) + return res; + verify_area((void *) data, 4); +--- 254,260 ---- + case 2: { + int tmp,res; + +! res = read_long(task[childno], addr, &tmp); + if (res < 0) + return res; + verify_area((void *) data, 4); +*************** +*** 267,280 **** + /* when I and D space are seperate, this will have to be fixed. */ + case 4: /* write the word at location addr. */ + case 5: +! if (put_long(childno, addr, data, 1)) +! return -EIO; +! return 0; + + case 6: /* write the word at location addr in the USER area */ + addr = addr >> 2; /* temproary hack. */ + if (addr < 0 || addr >= 17) +! return -EIO; + if (addr == ORIG_EAX) + return -EIO; + if (addr == EFL) { /* flags. */ +--- 277,288 ---- + /* when I and D space are seperate, this will have to be fixed. */ + case 4: /* write the word at location addr. */ + case 5: +! return write_long(task[childno],addr,data); + + case 6: /* write the word at location addr in the USER area */ + addr = addr >> 2; /* temproary hack. */ + if (addr < 0 || addr >= 17) +! return -EIO; + if (addr == ORIG_EAX) + return -EIO; + if (addr == EFL) { /* flags. */ +*************** +*** 281,287 **** + data &= FLAG_MASK; + data |= get_stack_long(child, EFL*4-MAGICNUMBER) & ~FLAG_MASK; + } +- + if (put_stack_long(child, 4*addr-MAGICNUMBER, data)) + return -EIO; + return 0; +--- 289,294 ---- +*** OLD/linux/mm/memory.c Tue Mar 17 22:35:13 1992 +--- linux/mm/memory.c Thu Mar 19 23:19:03 1992 +*************** +*** 429,436 **** + return 0; + } + +! void do_no_page(unsigned long error_code, +! unsigned long address, struct task_struct *tsk) + { + static unsigned int last_checked = 0; + int nr[4]; +--- 429,436 ---- + return 0; + } + +! void do_no_page(unsigned long error_code, unsigned long address, +! struct task_struct *tsk) + { + static unsigned int last_checked = 0; + int nr[4]; +*************** +*** 439,445 **** + int block,i; + struct inode * inode; + +! /* Trashing ? Make it interruptible, but don't penalize otherwise */ + for (i = 0; i < CHECK_LAST_NR; i++) + if ((address & 0xfffff000) == last_pages[i]) { + current->counter = 0; +--- 439,445 ---- + int block,i; + struct inode * inode; + +! /* Thrashing ? Make it interruptible, but don't penalize otherwise */ + for (i = 0; i < CHECK_LAST_NR; i++) + if ((address & 0xfffff000) == last_pages[i]) { + current->counter = 0; +*************** +*** 492,499 **** + return; + } + if (tsk == current) +! if (share_page(inode,tmp)) +! return; + if (!(page = get_free_page())) + oom(); + /* remember that 1 block is used for header */ +--- 492,499 ---- + return; + } + if (tsk == current) +! if (share_page(inode,tmp)) +! return; + if (!(page = get_free_page())) + oom(); + /* remember that 1 block is used for header */ +*** OLD/linux/include/linux/tty.h Sun Mar 15 02:43:54 1992 +--- linux/include/linux/tty.h Thu Mar 19 21:16:26 1992 +*************** +*** 68,83 **** + struct tty_queue *secondary; + }; + +! #define TTY_WRITE(tty) \ + do { \ + cli(); \ +! if (!(tty)->busy) { \ +! (tty)->busy = 1; \ + sti(); \ + (tty)->write((tty)); \ +! (tty)->busy = 0; \ +! } else \ + sti(); \ + } while (0) + + extern struct tty_struct tty_table[]; +--- 68,105 ---- + struct tty_queue *secondary; + }; + +! /* +! * so that interrupts won't be able to mess up the +! * queues, copy_to_cooked must be atomic with repect +! * to itself, as must tty->write. +! */ +! #define TTY_WRITE_BUSY 1 +! #define TTY_READ_BUSY 2 +! +! #define TTY_WRITE_FLUSH(tty) \ + do { \ + cli(); \ +! if (!EMPTY((tty)->write_q) && !(TTY_WRITE_BUSY & (tty)->busy)) { \ +! (tty)->busy |= TTY_WRITE_BUSY; \ + sti(); \ + (tty)->write((tty)); \ +! cli(); \ +! (tty)->busy &= ~TTY_WRITE_BUSY; \ +! } \ +! sti(); \ +! } while (0) +! +! #define TTY_READ_FLUSH(tty) \ +! do { \ +! cli(); \ +! if (!EMPTY((tty)->read_q) && !(TTY_READ_BUSY & (tty)->busy)) { \ +! (tty)->busy |= TTY_READ_BUSY; \ + sti(); \ ++ copy_to_cooked((tty)); \ ++ cli(); \ ++ (tty)->busy &= ~TTY_READ_BUSY; \ ++ } \ ++ sti(); \ + } while (0) + + extern struct tty_struct tty_table[]; diff --git a/Linux-0.95/patchs/mouse.tar b/Linux-0.95/patchs/mouse.tar new file mode 100644 index 00000000..af5f435f Binary files /dev/null and b/Linux-0.95/patchs/mouse.tar differ diff --git a/Linux-0.95/sources/sbin/acu.tar.Z b/Linux-0.95/sources/sbin/acu.tar.Z new file mode 100644 index 00000000..9b1c4243 Binary files /dev/null and b/Linux-0.95/sources/sbin/acu.tar.Z differ diff --git a/Linux-0.95/sources/sbin/diskbackup.tar.Z b/Linux-0.95/sources/sbin/diskbackup.tar.Z new file mode 100644 index 00000000..1ad5bfbe Binary files /dev/null and b/Linux-0.95/sources/sbin/diskbackup.tar.Z differ diff --git a/Linux-0.95/sources/sbin/fdformat.c b/Linux-0.95/sources/sbin/fdformat.c new file mode 100644 index 00000000..62c3b6d0 --- /dev/null +++ b/Linux-0.95/sources/sbin/fdformat.c @@ -0,0 +1,100 @@ +/* fdformat.c - Low-level formats a floppy disk. */ + +#include +#include +#include +#include +#include + + +static int ctrl; +struct floppy_struct param; + + +#define SECTOR_SIZE 512 +#define PERROR(msg) { perror(msg); exit(1); } + + +static void format_disk(char *name) +{ + struct format_descr descr; + int track; + char dummy; + + printf("Formatting ... "); + fflush(stdout); + if (ioctl(ctrl,FDFMTBEG,NULL) < 0) PERROR("\nioctl(FDFMTBEG)"); + for (track = 0; track < param.track; track++) { + descr.track = track; + descr.head = 0; + if (ioctl(ctrl,FDFMTTRK,(int) &descr) < 0) PERROR("\nioctl(FDFMTTRK)"); + printf("%3d\b\b\b",track); + fflush(stdout); + if (param.head == 2) { + descr.head = 1; + if (ioctl(ctrl,FDFMTTRK,(int) &descr) < 0) + PERROR("\nioctl(FDFMTTRK)"); + } + } + if (ioctl(ctrl,FDFMTEND,NULL) < 0) PERROR("\nioctl(FDFMTEND)"); + printf("done\n"); +} + + +static void verify_disk(char *name) +{ + unsigned char *data; + int fd,cyl_size,cyl,count; + + cyl_size = param.sect*param.head*512; + if ((data = (unsigned char *) malloc(cyl_size)) == NULL) PERROR("malloc"); + printf("Verifying ... "); + fflush(stdout); + if ((fd = open(name,O_RDONLY)) < 0) PERROR(name); + for (cyl = 0; cyl < param.track; cyl++) { + printf("%3d\b\b\b",cyl); + fflush(stdout); + if (read(fd,data,cyl_size) != cyl_size) PERROR("read"); + for (count = 0; count < cyl_size; count++) + if (data[count] != FD_FILL_BYTE) { + printf("bad data in cyl %d\nContinuing ... ",cyl); + fflush(stdout); + break; + } + } + printf("done\n"); + if (close(fd) < 0) PERROR("close"); +} + + +static void usage(char *name) +{ + char *this; + + if (this = strrchr(name,'/')) name = this+1; + fprintf(stderr,"usage: %s [ -n ] device\n",name); + exit(1); +} + + +main(int argc,char **argv) +{ + int verify; + char *name; + + name = argv[0]; + verify = 1; + if (argc > 1 && argv[1][0] == '-') { + if (argv[1][1] != 'n') usage(name); + verify = 0; + argc--; + argv++; + } + if (argc != 2) usage(name); + if ((ctrl = open(argv[1],3)) < 0) PERROR(argv[1]); + if (ioctl(ctrl,FDGETPRM,(int) ¶m) < 0) PERROR("ioctl(FDGETPRM)"); + printf("%sle-sided, %d tracks, %d sec/track. Total capacity %d kB.\n", + param.head ? "Doub" : "Sing",param.track,param.sect,param.size >> 1); + format_disk(argv[1]); + if (verify) verify_disk(argv[1]); +} diff --git a/Linux-0.95/sources/sbin/fdisk-0.91.tar.Z b/Linux-0.95/sources/sbin/fdisk-0.91.tar.Z new file mode 100644 index 00000000..e73a0d02 Binary files /dev/null and b/Linux-0.95/sources/sbin/fdisk-0.91.tar.Z differ diff --git a/Linux-0.95/sources/sbin/fdisk-0.92.tar.Z b/Linux-0.95/sources/sbin/fdisk-0.92.tar.Z new file mode 100644 index 00000000..20b5ab7c Binary files /dev/null and b/Linux-0.95/sources/sbin/fdisk-0.92.tar.Z differ diff --git a/Linux-0.95/sources/sbin/fdisk.c b/Linux-0.95/sources/sbin/fdisk.c new file mode 100644 index 00000000..5fb4fa31 --- /dev/null +++ b/Linux-0.95/sources/sbin/fdisk.c @@ -0,0 +1,110 @@ +#include +#include +#include +#include + +#include + +#define DISK_STRING "/dev/hd" + +static int current_minor; +static int indent; + +char * disk_type(unsigned char type) +{ + switch (type) { + case 1: return "12-bit DOS"; + case 4: return "16-bit DOS (<32M)"; + case 5: return "extended partition (don't use)"; + case 6: return "16-bit DOS (>=32M)"; + case 0x81: return "minix"; + } + return NULL; +} + +char * dev_name(int minor) +{ + char * ctl; + static char name[100]; + + if (minor & 0x3f) + ctl = "%s%c%d"; + else + ctl = "%s%c"; + sprintf(name,ctl,DISK_STRING,'a'+(minor >> 6),minor & 0x3f); + return name; +} + +void fdisk(int minor) +{ + char * type, * name; + char buffer[1024]; + struct partition * p; + int fd; + int i; + int this_minor = current_minor; + + if ((fd=open(name = dev_name(minor),O_RDONLY)) < 0) { + fprintf(stderr,"Unable to open %s\n",name); + exit(1); + } + if (1024 != read(fd,buffer,1024)) + return; + if (!(minor & 0x3f)) { + printf("Disk %d:\n", minor >> 6); + indent = 4; + } + p = (struct partition *) (buffer + 0x1be); + for (i=0 ; i<4 ; p++,i++) { + if (!p->nr_sects) + continue; + printf("%*c",indent,' '); + printf("%s: %6d blocks",dev_name(this_minor+i),p->nr_sects>>1); + if (p->boot_ind == 0x80) + printf(" active"); + else if (p->boot_ind) + printf(" active? (%02x)",p->boot_ind); + if (type = disk_type(p->sys_ind)) + printf(" %s\n",type); + else + printf(" unknown partition type 0x%02X\n",p->sys_ind); + if (p->sys_ind == 5 && (0x3f & current_minor) < 60) { + indent += 4; + current_minor += 4; + fdisk(this_minor+i); + indent -= 4; + } + } +/* check for disk-manager partitions */ + if (*(unsigned short *) (buffer + 0xfc) != 0x55AA) + return; + p = (struct partition *) (buffer + 0x1be); + for (i=4; i<16; i++) { + p--; + if ((current_minor & 0x3f) >= 60) + break; + if (!p->nr_sects) + continue; + printf("%*c",indent,' '); + printf("%s: %6d blocks disk-manager",dev_name(current_minor),p->nr_sects>>1); + if (p->boot_ind == 0x80) + printf(" active"); + else if (p->boot_ind) + printf(" active? (%02x)",p->boot_ind); + if (type = disk_type(p->sys_ind)) + printf(" %s\n",type); + else + printf(" unknown partition type 0x%02X\n",p->sys_ind); + current_minor++; + } +} + + +int main(int argc, char ** argv) +{ + current_minor = 1; + fdisk(0); + current_minor = 65; + fdisk(64); + return 0; +} diff --git a/Linux-0.95/sources/sbin/lastlogin.c b/Linux-0.95/sources/sbin/lastlogin.c new file mode 100644 index 00000000..75cca490 --- /dev/null +++ b/Linux-0.95/sources/sbin/lastlogin.c @@ -0,0 +1,114 @@ + +/*************************************************************************** + * Program: lastlogin (c)1987 ICUS Computer Group * + * By: Lenny Tropiano ...{ihnp4,mtune}!icus!lenny * + * * + * Program intent: This will allow programs like 'finger' and 'last' to * + * lookup in the file /usr/adm/lastlogin.log and see * + * when a particular user has logged-in. This saves * + * the necessity to keep /etc/wtmp around for a long * + * period of time. * + * * + * This program can be used/modified and redistributed * + * I declare it PUBLIC DOMAIN. Please give me credit * + * when credit is due. * + * * + * AT&T 3B1 compiling instructions for shared-libaries: * + * * + * $ cc -c -O lastlogin.c * + * $ ld -s -o lastlogin lastlogin.o /lib/shlib.ifile /lib/crt0s.o * + * $ mv lastlogin /etc * + * $ su * + * Password: * + * # chown adm /etc/lastlogin /usr/adm * + * # chgrp adm /etc/lastlogin /usr/adm * + * # chmod 4755 /etc/lastlogin * + * * + * Place a call to /etc/lastlogin in your /etc/localprofile * + * to be run on all user logins. * + ***************************************************************************/ +/*************************************************************************** + * Linux compiling instructions: * + * * + * $ gcc -o lastlogin lastlogin.c utmp2.o * + * utmp2.o is compiled from poe-IGL (1.2) * + * $ mv lastlogin /etc * + * $ su * + * Password: * + * # chown adm /etc/lastlogin /usr/adm * + * # chgrp adm /etc/lastlogin /usr/adm * + * # chmod 4755 /etc/lastlogin * + * * + * Place a call to /etc/lastlogin in your /etc/profile * + * to be run on all user logins. * + * * + * B.Bergt@informatik.tu-chemnitz.de * + ***************************************************************************/ + + /* Print the last login time and record the new time */ + +#include +#include +#include +#include +#include +#include + +#define LOGFILE "/usr/adm/lastlog" + +main() +{ + struct utmp *utent, *getutent(); + int fd; + long hrs, min, sec; + struct lastlog { + char ll_line[8]; + time_t ll_time; + } ll; + + if (access(LOGFILE, 0) == -1) { + if ((fd = creat(LOGFILE,0644)) == -1) { + fprintf(stderr,"Cannot create file %s: ", LOGFILE); + perror("creat()"); + exit(1); + } + } else { + if ((fd = open(LOGFILE,O_RDWR)) == -1) { + fprintf(stderr,"Cannot open file %s: ", LOGFILE); + perror("open()"); + exit(1); + } + } + + if (lseek(fd, (long)(getuid()*sizeof(struct lastlog)), 0) == -1) { + fprintf(stderr,"Cannot position file %s: ", LOGFILE); + perror("lseek()"); + exit(1); + } + + if (read(fd, (char *) &ll, sizeof ll) == sizeof ll && + ll.ll_time != 0L) { + printf("Last login: %.*s on %.*s\n" , 19 + , (char *) ctime(&ll.ll_time) , sizeof(ll.ll_line) + , ll.ll_line); + } else printf("Last login: [No Login information on record]\n"); + + sprintf(ll.ll_line, "%.8s", strrchr(ttyname(0), '/')+1); + setutent(); + while ((utent = getutent()) != NULL) + if (strcmp(utent->ut_line, ll.ll_line) == 0) + break; + + if (utent == NULL) { + fprintf(stderr,"Cannot locate utmp entry for tty\n"); + exit(1); + } + ll.ll_time = utent->ut_time; + endutent(); + + lseek(fd, (long)(getuid()*sizeof(struct lastlog)), 0); + write(fd, (char *) &ll, sizeof ll); + close(fd); + + exit(0); +} diff --git a/Linux-0.95/sources/sbin/lpd.tar.Z b/Linux-0.95/sources/sbin/lpd.tar.Z new file mode 100644 index 00000000..13fb7dd0 Binary files /dev/null and b/Linux-0.95/sources/sbin/lpd.tar.Z differ diff --git a/Linux-0.95/sources/sbin/ps095.tar.Z b/Linux-0.95/sources/sbin/ps095.tar.Z new file mode 100644 index 00000000..e0cc8d0d Binary files /dev/null and b/Linux-0.95/sources/sbin/ps095.tar.Z differ diff --git a/Linux-0.95/sources/sbin/su-1.0.c.Z b/Linux-0.95/sources/sbin/su-1.0.c.Z new file mode 100644 index 00000000..09f56456 Binary files /dev/null and b/Linux-0.95/sources/sbin/su-1.0.c.Z differ diff --git a/Linux-0.95/sources/sbin/user-adm.tar.Z b/Linux-0.95/sources/sbin/user-adm.tar.Z new file mode 100644 index 00000000..b3c31e65 Binary files /dev/null and b/Linux-0.95/sources/sbin/user-adm.tar.Z differ diff --git a/Linux-0.95/sources/sbin/vt102.codes b/Linux-0.95/sources/sbin/vt102.codes new file mode 100644 index 00000000..f98b87cf --- /dev/null +++ b/Linux-0.95/sources/sbin/vt102.codes @@ -0,0 +1,386 @@ + +Escape codes for vt102 terminal. + +All numbers below are octal. means numeric value, means character string. +If is missing it is 0 or in cursor movements 1. + +Reset and set modes + Set Modes + Esc [ ; ... ; h + 033 133 073 073 150 + Reset Modes + Esc [ ; ... ; l + 033 133 073 073 154 + + Where is + '2'= Lock keyboard (set); Unlock keyboard (reset) + '4'= Insert mode (set); Replace mode (reset) + '12'= Echo on (set); Echo off (reset) + '20'= Return = CR+LF (set); Return = CR (reset) + '?1'= Cursorkeys application (set); Cursorkeys normal (reset) + '?2'= Ansi (set); VT52 (reset) + '?3'= 132 char/row (set); 80 char/row (reset) + '?4'= Jump scroll (set); Smooth scroll (reset) + '?5'= Reverse screen (set); Normal screen (reset) + '?6'= Sets relative coordinates (set); Sets absolute coordinates (reset) + '?7'= Auto wrap (set); Auto wrap off (reset) + '?8'= Auto repeat on (set); Auto repeat off (reset) + '?18'= Send FF to printer after print screen (set); No char after PS (reset) + '?19'= Print screen prints full screen (set); PS prints scroll region (reset) + '?25'= Cursor on (set); Cursor off (reset) + +Set scrolling region (n1=upper,n2=lower) + Esc [ ; r + 033 133 073 162 + + +Cursor movement (=how many chars or lines), cursor stop at margin. + Up + Esc [ A + 033 133 101 + Down + Esc [ B + 033 133 102 + Right + Esc [ C + 033 133 103 + Left + Esc [ n D + 033 133 104 + Cursor position (=y,=x, from top of screen or scroll region) + Esc [ ; H + 033 133 073 110 + Or Esc [ ; f + 033 133 073 146 + Index (cursor down with scroll up when at margin) + Esc D + 033 104 + Reverse index (cursor up with scroll down when at margin) + Esc M + 033 115 + Next line (CR+Index) + Esc E + 033 105 + Save cursor and attribute + Esc 7 + 033 067 + Restore cursor and attribute + Esc 8 + 033 070 + + +Keybad character selection + Application keypad mode + Esc = + 033 075 + Numeric keypad mode + Esc > + 033 076 + + Keypadkeys codes generated + Numeric Application VT52 Application + 0 0 (060) Esc O p (033 117 160) Esc ? p (033 077 160) + 1 1 (061) Esc O q (033 117 161) Esc ? q (033 077 161) + 2 2 (062) Esc O r (033 117 162) Esc ? r (033 077 162) + 3 3 (063) Esc O s (033 117 163) Esc ? s (033 077 163) + 4 4 (064) Esc O t (033 117 164) Esc ? t (033 077 164) + 5 5 (065) Esc O u (033 117 165) Esc ? u (033 077 165) + 6 6 (066) Esc O v (033 117 166) Esc ? v (033 077 166) + 7 7 (067) Esc O w (033 117 167) Esc ? w (033 077 167) + 8 8 (070) Esc O x (033 117 170) Esc ? x (033 077 170) + 9 9 (071) Esc O y (033 117 171) Esc ? y (033 077 171) + - (minus) - (055) Esc O m (033 117 155) Esc ? m (033 077 155) + , (comma) , (054) Esc O l (033 117 154) Esc ? l (033 077 154) + . (period) . (056) Esc O n (033 117 156) Esc ? n (033 077 156) + Enter CR (015)* Esc O M (033 117 115) Esc ? M (033 077 115) + PF1 Esc O P Esc O P (033 117 120) Esc P (033 120) + PF2 Esc O Q Esc O Q (033 117 121) Esc Q (033 121) + PF3 Esc O R Esc O R (033 117 122) Esc R (033 122) + PF4 Esc O S Esc O S (033 117 123) Esc S (033 123) + * Or CR+LF (015 012) + + Cursorkeys codes generated (changed by set and reset modes '?1') + normal application + Up Esc [ A Esc O A + 033 133 101 033 117 101 + Down Esc [ B Esc O B + 033 133 102 033 117 102 + Right Esc [ C Esc O C + 033 133 103 033 117 103 + Left Esc [ D Esc O D + 033 133 104 033 117 104 + + +Select chaacter set + UK as G0 + Esc ( A + 033 050 101 + US as G0 + Esc ( B + 033 050 102 + Special characters and line drawing character set as G0 + Esc ( 0 + 033 050 060 + Alternate ROM as G0 + Esc ( 1 + 033 050 061 + Alternate ROM special characters character set as G0 + Esc ( 2 + 033 050 062 + + UK as G1 + Esc ) A + 033 051 101 + US as G1 + Esc ) B + 033 051 102 + Special characters and line drawing character set as G1 + Esc ) 0 + 033 051 060 + Alternate ROM as G1 + Esc ) 1 + 033 051 061 + Alternate ROM special characters character set as G1 + Esc ) 2 + 033 051 062 + + Selects G2 for one character + Esc N + 033 115 + Selects G3 for one character + Esc O + 033 117 + + +Set graphic rendition + Esc [ ; m + 033 133 073 156 + + Where is + 0 = Turn off attributes + 1 = Bold (Full) + 2 = Half + 4 = Underline + 5 = Blink + 7 = Reverse + 21 = Normal intensity + 22 = Normal intensity + 24 = Cancel underlined + 25 = Cancel blinking + 27 = Cancel reverse + +Tab stops + Set horizontal tab + Esc H + 033 110 + Clear horizontal tab + Esc [ g + 033 133 147 + Or Esc [ 0 g + 033 133 060 147 + Clear all horizontal tabs + Esc [ 3 g + 033 133 063 147 + + +Line attributes + Double-height + Top half + Esc # 3 + 033 043 063 + Bottom half + Esc # 4 + 033 043 064 + Single-width, single-height + Esc # 5 + 033 043 065 + Double-width + Esc # 6 + 033 043 066 + + +Erasing + Erase in line + End of line (including cursor position) + Esc [ K + 033 133 113 + Or Esc [ 0 K + 033 133 060 113 + Beginning of line (including cursor position) + Esc [ 1 K + 033 133 061 113 + Complete line + Esc [ 2 K + 033 133 062 113 + Erase in display + End of screen (including cursor position) + Esc [ J + 033 133 112 + Or Esc [ 0 J + 033 133 060 112 + Beginning of screen (including cursor position) + Esc [ 1 J + 033 133 061 112 + Complete display + Esc [ 2 J + 033 133 062 112 + + +Computer editing + Delete characters ( characters right from cursor + Esc [ P + 033 133 120 + Inser line ( lines) + Esc [ L + 033 133 114 + Delete line ( lines) + Esc [ M + 033 133 115 + + +Printing + Esc [ i + 033 133 151 + + Where is + ''= Same as '0' + '0'= Prints screen (full or scroll region) + '4'= Printer controller off + '5'= Printer controller on (Print all received chars to printer) + '?1'= Print cursor line + '?4'= Auto print off + '?5'= Auto print on (Prints line to printer when you exit from it) + + +Reports + Device status + Esc [ n + 033 133 156 + + Where is + '0'=Response Ready, no malfunctions detected + '3'=Malfunction, error in self-test. + '5'=Status report request + '6'=Request cursor position. + '?10'=Response to printer status request, All ok. + '?11'=Response to printer status request, Printer is not ready. + '?13'=Response to printer status request, No printer. + '?15'=Status report request from printer + + Cursor position raport (Response to request cursor position) + Esc [ ; R + 033 133 073 122 + Request terminal to identify itself (esc Z may not be supported in future) + Esc [ c + 033 133 143 + Esc [ 0 c + 033 133 060 143 + Esc Z + 033 132 + Response to terminal identify (VT102) + Esc [ ? 6 c + 033 133 077 066 143 + + +Reset to initial state + Esc c + 033 143 + + +Tests + Invoke confidence test + Esc [ 2 ; y + 033 133 062 073 171 + + Where is + '1'= Power-up test + '2'= Data loopback test + '4'= EIA loopback test + '9'= Power-up tests (continuously) + '10'= Data loopback tests (continuously) + '12'= EIA loopback tests (continuously) + '16'= Printer loopback test + '24'= Printer loopback tests (continuously) + + +Screen adjustments + Esc # 8 + 033 043 070 + + +Keyboard indicator + Led L1 off + Esc [ 0 q + 033 133 060 181 + Led L1 on + Esc [ 1 q + 033 133 061 181 + + + +VT52 sequences + Ansi mode + Esc < + 033 074 + Cursor positioning + Up Esc A + 033 101 + Down Esc B + 033 102 + Right Esc C + 033 103 + Left Esc D + 033 104 + Home Esc H + 033 110 + Direct cursor address + Esc Y + 033 131 + Reverse linefeed Esc I + 033 111 + Erase to end of line Esc K + 033 113 + Erase to end of screen Esc J + 033 112 + Auto print on Esc ^ + 033 136 + Auto print off Esc + 033 137 + Printer controller on Esc W + 033 127 + Printer controller off Esc X + 033 130 + Print cursor line Esc V + 033 135 + Print screen Esc ] + 033 135 + Indentify request Esc Z + 033 132 + Response to indetify Esc / Z + request (VT52) 033 057 132 + Special charset (same Esc F + as line draw in VT102 033 106 + Normal char set Esc G + 033 107 + + +Control characters + 000 = Null (fill character) + 003 = ETX (Can be selected half-duplex turnaround char) + 004 = EOT (Can be turnaround or disconnect char, if turn, then DLE-EOT=disc.) + 005 = ENQ (Transmits answerback message) + 007 = BEL (Generates bell tone) + 010 = BS (Moves cursor left) + 011 = HT (Moves cursor to next tab) + 012 = LF (Linefeed or New line operation) + 013 = VT (Processed as LF) + 014 = FF (Processed as LF, can be selected turnaround char) + 015 = CR (Moves cursor to left margin, can be turnaround char) + 016 = SO (Selects G1 charset) + 017 = SI (Selects G0 charset) + 021 = DC1 (XON, causes terminal to continue transmit) + 023 = DC3 (XOFF, causes terminal to stop transmitting) + 030 = CAN (Cancels escape sequence) + 032 = SUB (Processed as CAN) + 033 = ESC (Processed as sequence indicator) + diff --git a/Linux-0.95/sources/sbin/vttest.tar.Z b/Linux-0.95/sources/sbin/vttest.tar.Z new file mode 100644 index 00000000..769ae9dc Binary files /dev/null and b/Linux-0.95/sources/sbin/vttest.tar.Z differ diff --git a/Linux-0.95/sources/system/0.95b-gcc2.1-patch.tar.Z b/Linux-0.95/sources/system/0.95b-gcc2.1-patch.tar.Z new file mode 100644 index 00000000..1c46ba35 Binary files /dev/null and b/Linux-0.95/sources/system/0.95b-gcc2.1-patch.tar.Z differ diff --git a/Linux-0.95/sources/system/README b/Linux-0.95/sources/system/README new file mode 100644 index 00000000..458c23e2 --- /dev/null +++ b/Linux-0.95/sources/system/README @@ -0,0 +1,55 @@ +To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU +From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) +Crossposted-To: alt.os.linux +Subject: Second 0.95a alpha-patch, part 1/2 +Date: 4 Apr 92 14:42:10 GMT + +This is the promised patch to 0.95a, which hopefully corrects some of +the problems encountered. This is /not/ an offical new release: it's +just a set of patches to get the same kernel I am currently running. + +Bugfixes: + +- extended partitions should finally work correctly (this release also + contains code for the hd-ioctl call, needed for fdisk). Code mostly + by hedrick. + +- I corrected my original ptrace-fix (writing a long word to another + process' data space could fail with my original patches) + +- 387-emulation bug with the instructions "fcom[p] %st(x)" which + resulted in bad results on non-387 machines with newer versions of + gcc. The emulation is still ugly, but it seems to work. + +- the cooked mode deletion/linekill bugs should be fixed. + +- various error-returns were wrong: I correted some of them (thanks to + bruce evans who pointed them out). The bad error-values resulted in + incorrect or spurious error-messages from 'rm' etc. + +- various minor fixes (including some in the hd-driver: this might help + persons with unexpected-interrupt and/or timeout errors) + +Additionally this version contains VFS-code from entropy, and a +readdir() system call needed for the VFS. The latter was inspired by +patches sent by Remy Card, who did it with a getdirents sys-call. My +version is slightly simpler, but is probably slower. Things might yet +change. + +The installation has also changed slightly: the keyboard type and +math-emulation are specified in the main Makefile. That one also +contains the -fcombine-regs flag needed for 1.40. The other makefiles +should no longer need editing. + +I've also incorporated the ps095 kernel patches: to get the actual +user-level stuff you still have to get the ps-distribution. Printer +ports /still/ aren't in there, but this time I positively /promise/ to +put it in next week. Really. + +People who have been patching their kernel might have problems getting +this patch to work: it was made against a clean 0.95a kernel. I'll +consider a patched-up kernel version 0.95c - and I'd appreciate if +future patches to me would be sent against this version. I'll still +accept older patches, or course. + + Linus diff --git a/Linux-0.95/sources/system/diffs b/Linux-0.95/sources/system/diffs new file mode 100644 index 00000000..3a320fec --- /dev/null +++ b/Linux-0.95/sources/system/diffs @@ -0,0 +1,5168 @@ +*** ../0.95a/linux/Makefile Tue Mar 17 00:08:56 1992 +--- linux/Makefile Sat Apr 4 17:33:02 1992 +*************** +*** 1,7 **** +--- 1,44 ---- + # ++ # comment this line if you don't want the emulation-code ++ # ++ ++ MATH_EMULATION = -DKERNEL_MATH_EMULATION ++ ++ # ++ # uncomment the correct keyboard: ++ # ++ ++ KEYBOARD = -DKBD_FINNISH ++ # KEYBOARD = -DKBD_US ++ # KEYBOARD = -DKBD_GR ++ # KEYBOARD = -DKBD_FR ++ # KEYBOARD = -DKBD_UK ++ # KEYBOARD = -DKBD_DK ++ ++ # ++ # uncomment this line if you are using gcc-1.40 ++ # ++ #GCC_OPT = -fcombine-regs ++ ++ # ++ # standard CFLAGS ++ # ++ ++ CFLAGS =-Wall -O -fstrength-reduce -fomit-frame-pointer $(GCC_OPT) ++ ++ # ++ # ROOT_DEV specifies the default root-device when making the image. ++ # This can be either FLOPPY, /dev/xxxx or empty, in which case the ++ # default of FLOPPY is used by 'build'. ++ # ++ ++ ROOT_DEV = /dev/hdb1 ++ ++ # + # if you want the ram-disk device, define this to be the + # size in blocks. + # ++ + #RAMDISK = -DRAMDISK=512 + + AS86 =as86 -0 -a +*************** +*** 9,26 **** + + AS =as + LD =ld +! LDFLAGS =-s -x -M + CC =gcc $(RAMDISK) +! CFLAGS =-Wall -O -fstrength-reduce -fomit-frame-pointer + CPP =cpp -nostdinc -Iinclude + +- # +- # ROOT_DEV specifies the default root-device when making the image. +- # This can be either FLOPPY, /dev/xxxx or empty, in which case the +- # default of FLOPPY is used by 'build'. +- # +- ROOT_DEV=/dev/hdb1 +- + ARCHIVES =kernel/kernel.o mm/mm.o fs/fs.o + FILESYSTEMS =fs/minix/minix.o + DRIVERS =kernel/blk_drv/blk_drv.a kernel/chr_drv/chr_drv.a +--- 46,57 ---- + + AS =as + LD =ld +! #LDFLAGS =-s -x -M +! LDFLAGS = -M + CC =gcc $(RAMDISK) +! MAKE =make CFLAGS="$(CFLAGS)" + CPP =cpp -nostdinc -Iinclude + + ARCHIVES =kernel/kernel.o mm/mm.o fs/fs.o + FILESYSTEMS =fs/minix/minix.o + DRIVERS =kernel/blk_drv/blk_drv.a kernel/chr_drv/chr_drv.a +*************** +*** 39,45 **** + all: Image + + Image: boot/bootsect boot/setup tools/system tools/build +! tools/build boot/bootsect boot/setup tools/system $(ROOT_DEV) > Image + sync + + disk: Image +--- 70,79 ---- + all: Image + + Image: boot/bootsect boot/setup tools/system tools/build +! cp tools/system system.tmp +! strip system.tmp +! tools/build boot/bootsect boot/setup system.tmp $(ROOT_DEV) > Image +! rm system.tmp + sync + + disk: Image +*************** +*** 62,89 **** + -o tools/system > System.map + + kernel/math/math.a: dummy +! (cd kernel/math; make) + + kernel/blk_drv/blk_drv.a: dummy +! (cd kernel/blk_drv; make) + + kernel/chr_drv/chr_drv.a: dummy +! (cd kernel/chr_drv; make) + + kernel/kernel.o: dummy +! (cd kernel; make) + + mm/mm.o: dummy +! (cd mm; make) + + fs/fs.o: dummy +! (cd fs; make) + + fs/minix/minix.o: dummy +! (cd fs/minix; make) + + lib/lib.a: dummy +! (cd lib; make) + + boot/setup: boot/setup.s + $(AS86) -o boot/setup.o boot/setup.s +--- 96,123 ---- + -o tools/system > System.map + + kernel/math/math.a: dummy +! (cd kernel/math; $(MAKE) MATH_EMULATION="$(MATH_EMULATION)") + + kernel/blk_drv/blk_drv.a: dummy +! (cd kernel/blk_drv; $(MAKE)) + + kernel/chr_drv/chr_drv.a: dummy +! (cd kernel/chr_drv; $(MAKE) KEYBOARD="$(KEYBOARD)") + + kernel/kernel.o: dummy +! (cd kernel; $(MAKE)) + + mm/mm.o: dummy +! (cd mm; $(MAKE)) + + fs/fs.o: dummy +! (cd fs; $(MAKE)) + + fs/minix/minix.o: dummy +! (cd fs/minix; $(MAKE)) + + lib/lib.a: dummy +! (cd lib; $(MAKE)) + + boot/setup: boot/setup.s + $(AS86) -o boot/setup.o boot/setup.s +*************** +*** 127,133 **** + include/sys/types.h include/sys/time.h include/time.h include/sys/times.h \ + include/sys/utsname.h include/sys/param.h include/sys/resource.h \ + include/utime.h include/linux/tty.h include/termios.h include/linux/sched.h \ +! include/linux/head.h include/linux/fs.h include/linux/mm.h \ +! include/linux/kernel.h include/signal.h include/asm/system.h \ +! include/asm/io.h include/stddef.h include/stdarg.h include/fcntl.h \ +! include/string.h +--- 161,167 ---- + include/sys/types.h include/sys/time.h include/time.h include/sys/times.h \ + include/sys/utsname.h include/sys/param.h include/sys/resource.h \ + include/utime.h include/linux/tty.h include/termios.h include/linux/sched.h \ +! include/linux/head.h include/linux/fs.h include/sys/dirent.h \ +! include/limits.h include/linux/mm.h include/linux/kernel.h include/signal.h \ +! include/asm/system.h include/asm/io.h include/stddef.h include/stdarg.h \ +! include/fcntl.h include/string.h +*** ../0.95a/linux/boot/bootsect.S Sat Jan 18 19:01:36 1992 +--- linux/boot/bootsect.S Thu Apr 2 23:18:19 1992 +*************** +*** 8,17 **** + ! + ! bootsect.s (C) 1991 Linus Torvalds + ! modified by Drew Eckhardt + ! + ! bootsect.s is loaded at 0x7c00 by the bios-startup routines, and moves +! ! iself out of the way to address 0x90000, and jumps there. + ! + ! It then loads 'setup' directly after itself (0x90200), and the system + ! at 0x10000, using BIOS interrupts. + ! +--- 8,21 ---- + ! + ! bootsect.s (C) 1991 Linus Torvalds + ! modified by Drew Eckhardt ++ ! modified by Bruce Evans (bde) + ! + ! bootsect.s is loaded at 0x7c00 by the bios-startup routines, and moves +! ! itself out of the way to address 0x90000, and jumps there. + ! ++ ! bde - should not jump blindly, there may be systems with only 512K low ++ ! memory. Use int 0x12 to get the top of memory, etc. ++ ! + ! It then loads 'setup' directly after itself (0x90200), and the system + ! at 0x10000, using BIOS interrupts. + ! +*************** +*** 22,51 **** + ! + ! The loader has been made as simple as possible, and continuos + ! read errors will result in a unbreakable loop. Reboot by hand. It +! ! loads pretty fast by getting whole sectors at a time whenever possible. + +- .globl begtext, begdata, begbss, endtext, enddata, endbss + .text +- begtext: +- .data +- begdata: +- .bss +- begbss: +- .text + +! SETUPLEN = 4 ! nr of setup-sectors +! BOOTSEG = 0x07c0 ! original address of boot-sector +! INITSEG = DEF_INITSEG ! we move boot here - out of the way +! SETUPSEG = DEF_SETUPSEG ! setup starts here +! SYSSEG = DEF_SYSSEG ! system loaded at 0x10000 (65536). +! ENDSEG = SYSSEG + SYSSIZE ! where to stop loading + + ! ROOT_DEV & SWAP_DEV are now written by "build". + ROOT_DEV = 0 + SWAP_DEV = 0 + +! entry start +! start: + mov ax,#BOOTSEG + mov ds,ax + mov ax,#INITSEG +--- 26,52 ---- + ! + ! The loader has been made as simple as possible, and continuos + ! read errors will result in a unbreakable loop. Reboot by hand. It +! ! loads pretty fast by getting whole tracks at a time whenever possible. + + .text + +! SETUPSECS = 4 ! nr of setup-sectors +! BOOTSEG = 0x07C0 ! original address of boot-sector +! INITSEG = DEF_INITSEG ! we move boot here - out of the way +! SETUPSEG = DEF_SETUPSEG ! setup starts here +! SYSSEG = DEF_SYSSEG ! system loaded at 0x10000 (65536). +! ENDSEG = SYSSEG + SYSSIZE ! where to stop loading + + ! ROOT_DEV & SWAP_DEV are now written by "build". + ROOT_DEV = 0 + SWAP_DEV = 0 + +! ! ld86 requires an entry symbol. This may as well be the usual one. +! .globl _main +! _main: +! #if 0 /* hook for debugger, harmless unless BIOS is fussy (old HP) */ +! int 3 +! #endif + mov ax,#BOOTSEG + mov ds,ax + mov ax,#INITSEG +*************** +*** 55,71 **** + sub di,di + cld + rep +! movw + jmpi go,INITSEG + + go: mov ax,cs +! mov dx,#0xfef4 ! arbitrary value >>512 - disk parm size + + mov ds,ax + mov es,ax + push ax + +! mov ss,ax ! put stack at 0x9ff00 - 12. + mov sp,dx + /* + * Many BIOS's default disk parameter tables will not +--- 56,80 ---- + sub di,di + cld + rep +! movsw + jmpi go,INITSEG + + go: mov ax,cs +! mov dx,#0x4000-12 ! 0x4000 is arbitrary value >= length of +! ! bootsect + length of setup + room for stack +! ! 12 is disk parm size + ++ ! bde - changed 0xff00 to 0x4000 to use debugger at 0x6400 up (bde). We ++ ! wouldn't have to worry about this if we checked the top of memory. Also ++ ! my BIOS can be configured to put the wini drive tables in high memory ++ ! instead of in the vector table. The old stack might have clobbered the ++ ! drive table. ++ + mov ds,ax + mov es,ax + push ax + +! mov ss,ax ! put stack at INITSEG:0x4000-12. + mov sp,dx + /* + * Many BIOS's default disk parameter tables will not +*************** +*** 96,102 **** + + rep + seg gs +! movw + + mov di,dx + movb 4(di),*18 ! patch sector count +--- 105,111 ---- + + rep + seg gs +! movsw + + mov di,dx + movb 4(di),*18 ! patch sector count +*************** +*** 121,127 **** + xor dx, dx ! drive 0, head 0 + mov cx,#0x0002 ! sector 2, track 0 + mov bx,#0x0200 ! address = 512, in INITSEG +! mov ax,#0x0200+SETUPLEN ! service 2, nr of sectors + int 0x13 ! read it + jnc ok_load_setup ! ok - continue + +--- 130,137 ---- + xor dx, dx ! drive 0, head 0 + mov cx,#0x0002 ! sector 2, track 0 + mov bx,#0x0200 ! address = 512, in INITSEG +! mov ax,#0x0200+SETUPSECS ! service 2, nr of sectors +! ! (assume all on head 0, track 0) + int 0x13 ! read it + jnc ok_load_setup ! ok - continue + +*************** +*** 134,149 **** + xor dl, dl ! reset FDC + xor ah, ah + int 0x13 +! j load_setup + + ok_load_setup: + + ! Get disk drive parameters, specifically nr of sectors/track + + xor dl,dl + mov ah,#0x08 ! AH=8 is get drive parameters + int 0x13 + xor ch,ch + seg cs + mov sectors,cx + mov ax,#INITSEG +--- 144,186 ---- + xor dl, dl ! reset FDC + xor ah, ah + int 0x13 +! jmp load_setup + + ok_load_setup: + + ! Get disk drive parameters, specifically nr of sectors/track + ++ #if 0 ++ ++ ! bde - the Phoenix BIOS manual says function 0x08 only works for fixed ++ ! disks. It doesn't work for one of my BIOS's (1987 Award). It was ++ ! fatal not to check the error code. ++ + xor dl,dl + mov ah,#0x08 ! AH=8 is get drive parameters + int 0x13 + xor ch,ch ++ #else ++ ++ ! It seems that there is no BIOS call to get the number of sectors. Guess ++ ! 18 sectors if sector 18 can be read, 15 if sector 15 can be read. ++ ! Otherwise guess 9. ++ ++ xor dx, dx ! drive 0, head 0 ++ mov cx,#0x0012 ! sector 18, track 0 ++ mov bx,#0x0200+SETUPSECS*0x200 ! address after setup (es = cs) ++ mov ax,#0x0201 ! service 2, 1 sector ++ int 0x13 ++ jnc got_sectors ++ mov cl,#0x0f ! sector 15 ++ mov ax,#0x0201 ! service 2, 1 sector ++ int 0x13 ++ jnc got_sectors ++ mov cl,#0x09 ++ ++ #endif ++ ++ got_sectors: + seg cs + mov sectors,cx + mov ax,#INITSEG +*************** +*** 205,211 **** + ! + ! in: es - starting address segment (normally 0x1000) + ! +! sread: .word 1+SETUPLEN ! sectors read of current track + head: .word 0 ! current head + track: .word 0 ! current track + +--- 242,248 ---- + ! + ! in: es - starting address segment (normally 0x1000) + ! +! sread: .word 1+SETUPSECS ! sectors read of current track + head: .word 0 ! current head + track: .word 0 ! current track + +*************** +*** 264,277 **** + int 0x10 + popa + +! mov dx,track +! mov cx,sread +! inc cx +! mov ch,dl +! mov dx,head +! mov dh,dl +! and dx,#0x0100 +! mov ah,#2 + + push dx ! save for error dump + push cx +--- 301,314 ---- + int 0x10 + popa + +! mov dx,track +! mov cx,sread +! inc cx +! mov ch,dl +! mov dx,head +! mov dh,dl +! and dx,#0x0100 +! mov ah,#2 + + push dx ! save for error dump + push cx +*************** +*** 278,286 **** + push bx + push ax + +! int 0x13 +! jc bad_rt +! add sp, #8 + popa + ret + +--- 315,323 ---- + push bx + push ax + +! int 0x13 +! jc bad_rt +! add sp, #8 + popa + ret + +*************** +*** 317,332 **** + print_loop: + push cx ! save count left + call print_nl ! nl for readability + jae no_reg ! see if register name is needed + +! mov ax, #0xe05 + 0x41 - 1 + sub al, cl + int 0x10 + +! mov al, #0x58 ! X + int 0x10 + +! mov al, #0x3a ! : + int 0x10 + + no_reg: +--- 354,371 ---- + print_loop: + push cx ! save count left + call print_nl ! nl for readability ++ ++ cmp cl, 5 + jae no_reg ! see if register name is needed + +! mov ax, #0xe05 + 'A - 1 + sub al, cl + int 0x10 + +! mov al, #'X + int 0x10 + +! mov al, #': + int 0x10 + + no_reg: +*************** +*** 356,365 **** + mov ah, #0xe + mov al, dl ! mask off so we have only next nibble + and al, #0xf +! add al, #0x30 ! convert to 0 based digit, '0' +! cmp al, #0x39 ! check for overflow + jbe good_digit +! add al, #0x41 - 0x30 - 0xa ! 'A' - '0' - 0xa + + good_digit: + int 0x10 +--- 395,404 ---- + mov ah, #0xe + mov al, dl ! mask off so we have only next nibble + and al, #0xf +! add al, #'0 ! convert to 0-based digit +! cmp al, #'9 ! check for overflow + jbe good_digit +! add al, #'A - '0 - 10 + + good_digit: + int 0x10 +*************** +*** 394,404 **** + .word ROOT_DEV + boot_flag: + .word 0xAA55 +- +- .text +- endtext: +- .data +- enddata: +- .bss +- endbss: +- +--- 433,435 ---- +*** ../0.95a/linux/boot/setup.S Sat Mar 14 23:13:30 1992 +--- linux/boot/setup.S Wed Mar 25 02:30:42 1992 +*************** +*** 217,222 **** +--- 217,238 ---- + jnz empty_8042 ! yes - loop + ret + ++ getkey: ++ in al,#0x60 ! Quick and dirty... ++ .word 0x00eb,0x00eb ! jmp $+2, jmp $+2 ++ mov bl,al ++ in al,#0x61 ++ .word 0x00eb,0x00eb ++ mov ah,al ++ or al,#0x80 ++ out #0x61,al ++ .word 0x00eb,0x00eb ++ mov al,ah ++ out #0x61,al ++ .word 0x00eb,0x00eb ++ mov al,bl ++ ret ++ + ! Routine trying to recognize type of SVGA-board present (if any) + ! and if it recognize one gives the choices of resolution it offers. + ! If one is found the resolution chosen is given by al,ah (rows,cols). +*************** +*** 233,239 **** + cmp al,#0x82 + jb nokey + jmp flush +! nokey: in al,#0x60 + cmp al,#0x82 + jb nokey + cmp al,#0xe0 +--- 249,255 ---- + cmp al,#0x82 + jb nokey + jmp flush +! nokey: call getkey + cmp al,#0x82 + jb nokey + cmp al,#0xe0 +*************** +*** 481,487 **** + call prtstr + pop si + add cl,#0x80 +! nonum: in al,#0x60 ! Quick and dirty... + cmp al,#0x82 + jb nonum + cmp al,#0x8b +--- 497,503 ---- + call prtstr + pop si + add cl,#0x80 +! nonum: call getkey + cmp al,#0x82 + jb nonum + cmp al,#0x8b +*** ../0.95a/linux/fs/Makefile Thu Mar 5 23:36:44 1992 +--- linux/fs/Makefile Sat Apr 4 17:33:10 1992 +*************** +*** 1,10 **** + AR =ar + AS =as +- CC =gcc + LD =ld +! CFLAGS =-Wall -O -fstrength-reduce -fomit-frame-pointer \ +! -fno-defer-pop -nostdinc -I../include +! CPP =gcc -E -nostdinc -I../include + + .c.s: + $(CC) $(CFLAGS) \ +--- 1,17 ---- ++ # ++ # Makefile for the linux filesystem. ++ # ++ # Note! Dependencies are done automagically by 'make dep', which also ++ # removes any old dependencies. DON'T put your own dependencies here ++ # unless it's something special (ie not a .c file). ++ # ++ # Note 2! The CFLAGS definitions are now in the main makefile... ++ + AR =ar + AS =as + LD =ld +! CC =gcc -nostdinc -I../include +! CPP =cpp -nostdinc -I../include + + .c.s: + $(CC) $(CFLAGS) \ +*************** +*** 36,118 **** + ### Dependencies: + block_dev.o : block_dev.c ../include/errno.h ../include/linux/sched.h \ + ../include/linux/head.h ../include/linux/fs.h ../include/sys/types.h \ +! ../include/linux/mm.h ../include/linux/kernel.h ../include/signal.h \ +! ../include/sys/param.h ../include/sys/time.h ../include/time.h \ +! ../include/sys/resource.h ../include/asm/segment.h ../include/asm/system.h + buffer.o : buffer.c ../include/stdarg.h ../include/linux/config.h \ + ../include/linux/sched.h ../include/linux/head.h ../include/linux/fs.h \ +! ../include/sys/types.h ../include/linux/mm.h ../include/linux/kernel.h \ +! ../include/signal.h ../include/sys/param.h ../include/sys/time.h \ +! ../include/time.h ../include/sys/resource.h ../include/asm/system.h \ +! ../include/asm/io.h +! char_dev.o : char_dev.c ../include/errno.h ../include/sys/types.h \ +! ../include/linux/sched.h ../include/linux/head.h ../include/linux/fs.h \ + ../include/linux/mm.h ../include/linux/kernel.h ../include/signal.h \ + ../include/sys/param.h ../include/sys/time.h ../include/time.h \ +! ../include/sys/resource.h ../include/asm/segment.h ../include/asm/io.h + exec.o : exec.c ../include/signal.h ../include/sys/types.h \ + ../include/errno.h ../include/string.h ../include/sys/stat.h \ +! ../include/a.out.h ../include/linux/fs.h ../include/linux/sched.h \ +! ../include/linux/head.h ../include/linux/mm.h ../include/linux/kernel.h \ +! ../include/sys/param.h ../include/sys/time.h ../include/time.h \ +! ../include/sys/resource.h ../include/asm/segment.h + fcntl.o : fcntl.c ../include/string.h ../include/errno.h \ + ../include/linux/sched.h ../include/linux/head.h ../include/linux/fs.h \ +! ../include/sys/types.h ../include/linux/mm.h ../include/linux/kernel.h \ +! ../include/signal.h ../include/sys/param.h ../include/sys/time.h \ +! ../include/time.h ../include/sys/resource.h ../include/asm/segment.h \ +! ../include/fcntl.h ../include/sys/stat.h +! file_table.o : file_table.c ../include/linux/fs.h ../include/sys/types.h + inode.o : inode.c ../include/string.h ../include/sys/stat.h \ + ../include/sys/types.h ../include/linux/sched.h ../include/linux/head.h \ +! ../include/linux/fs.h ../include/linux/mm.h ../include/linux/kernel.h \ +! ../include/signal.h ../include/sys/param.h ../include/sys/time.h \ +! ../include/time.h ../include/sys/resource.h ../include/linux/minix_fs.h \ +! ../include/asm/system.h + ioctl.o : ioctl.c ../include/string.h ../include/errno.h \ + ../include/sys/stat.h ../include/sys/types.h ../include/linux/sched.h \ +! ../include/linux/head.h ../include/linux/fs.h ../include/linux/mm.h \ +! ../include/linux/kernel.h ../include/signal.h ../include/sys/param.h \ +! ../include/sys/time.h ../include/time.h ../include/sys/resource.h + namei.o : namei.c ../include/linux/sched.h ../include/linux/head.h \ +! ../include/linux/fs.h ../include/sys/types.h ../include/linux/mm.h \ +! ../include/linux/kernel.h ../include/signal.h ../include/sys/param.h \ +! ../include/sys/time.h ../include/time.h ../include/sys/resource.h \ +! ../include/linux/minix_fs.h ../include/asm/segment.h ../include/string.h \ +! ../include/fcntl.h ../include/errno.h ../include/const.h \ +! ../include/sys/stat.h + open.o : open.c ../include/string.h ../include/errno.h ../include/fcntl.h \ + ../include/sys/types.h ../include/utime.h ../include/sys/stat.h \ + ../include/linux/sched.h ../include/linux/head.h ../include/linux/fs.h \ +! ../include/linux/mm.h ../include/linux/kernel.h ../include/signal.h \ +! ../include/sys/param.h ../include/sys/time.h ../include/time.h \ +! ../include/sys/resource.h ../include/asm/segment.h + pipe.o : pipe.c ../include/signal.h ../include/sys/types.h \ + ../include/errno.h ../include/termios.h ../include/fcntl.h \ + ../include/linux/sched.h ../include/linux/head.h ../include/linux/fs.h \ +! ../include/linux/mm.h ../include/linux/kernel.h ../include/sys/param.h \ +! ../include/sys/time.h ../include/time.h ../include/sys/resource.h \ +! ../include/asm/segment.h +! read_write.o : read_write.c ../include/sys/stat.h ../include/sys/types.h \ +! ../include/errno.h ../include/linux/kernel.h ../include/linux/sched.h \ +! ../include/linux/head.h ../include/linux/fs.h ../include/linux/mm.h \ +! ../include/signal.h ../include/sys/param.h ../include/sys/time.h \ + ../include/time.h ../include/sys/resource.h ../include/asm/segment.h + select.o : select.c ../include/linux/fs.h ../include/sys/types.h \ +! ../include/linux/kernel.h ../include/linux/tty.h ../include/termios.h \ +! ../include/linux/sched.h ../include/linux/head.h ../include/linux/mm.h \ +! ../include/signal.h ../include/sys/param.h ../include/sys/time.h \ +! ../include/time.h ../include/sys/resource.h ../include/asm/segment.h \ +! ../include/asm/system.h ../include/sys/stat.h ../include/string.h \ +! ../include/const.h ../include/errno.h + stat.o : stat.c ../include/errno.h ../include/sys/stat.h \ +! ../include/sys/types.h ../include/linux/fs.h ../include/linux/sched.h \ +! ../include/linux/head.h ../include/linux/mm.h ../include/linux/kernel.h \ +! ../include/signal.h ../include/sys/param.h ../include/sys/time.h \ +! ../include/time.h ../include/sys/resource.h ../include/asm/segment.h +! super.o : super.c ../include/linux/config.h ../include/linux/sched.h \ +! ../include/linux/head.h ../include/linux/fs.h ../include/sys/types.h \ + ../include/linux/mm.h ../include/linux/kernel.h ../include/signal.h \ + ../include/sys/param.h ../include/sys/time.h ../include/time.h \ +! ../include/sys/resource.h ../include/linux/minix_fs.h \ +! ../include/asm/system.h ../include/errno.h ../include/sys/stat.h +--- 43,137 ---- + ### Dependencies: + block_dev.o : block_dev.c ../include/errno.h ../include/linux/sched.h \ + ../include/linux/head.h ../include/linux/fs.h ../include/sys/types.h \ +! ../include/sys/dirent.h ../include/limits.h ../include/linux/mm.h \ +! ../include/linux/kernel.h ../include/signal.h ../include/sys/param.h \ +! ../include/sys/time.h ../include/time.h ../include/sys/resource.h \ +! ../include/asm/segment.h ../include/asm/system.h + buffer.o : buffer.c ../include/stdarg.h ../include/linux/config.h \ + ../include/linux/sched.h ../include/linux/head.h ../include/linux/fs.h \ +! ../include/sys/types.h ../include/sys/dirent.h ../include/limits.h \ + ../include/linux/mm.h ../include/linux/kernel.h ../include/signal.h \ + ../include/sys/param.h ../include/sys/time.h ../include/time.h \ +! ../include/sys/resource.h ../include/asm/system.h ../include/asm/io.h +! char_dev.o : char_dev.c ../include/errno.h ../include/sys/types.h \ +! ../include/linux/sched.h ../include/linux/head.h ../include/linux/fs.h \ +! ../include/sys/dirent.h ../include/limits.h ../include/linux/mm.h \ +! ../include/linux/kernel.h ../include/signal.h ../include/sys/param.h \ +! ../include/sys/time.h ../include/time.h ../include/sys/resource.h \ +! ../include/asm/segment.h ../include/asm/io.h + exec.o : exec.c ../include/signal.h ../include/sys/types.h \ + ../include/errno.h ../include/string.h ../include/sys/stat.h \ +! ../include/a.out.h ../include/linux/fs.h ../include/sys/dirent.h \ +! ../include/limits.h ../include/linux/sched.h ../include/linux/head.h \ +! ../include/linux/mm.h ../include/linux/kernel.h ../include/sys/param.h \ +! ../include/sys/time.h ../include/time.h ../include/sys/resource.h \ +! ../include/asm/segment.h + fcntl.o : fcntl.c ../include/string.h ../include/errno.h \ + ../include/linux/sched.h ../include/linux/head.h ../include/linux/fs.h \ +! ../include/sys/types.h ../include/sys/dirent.h ../include/limits.h \ +! ../include/linux/mm.h ../include/linux/kernel.h ../include/signal.h \ +! ../include/sys/param.h ../include/sys/time.h ../include/time.h \ +! ../include/sys/resource.h ../include/asm/segment.h ../include/fcntl.h \ +! ../include/sys/stat.h +! file_table.o : file_table.c ../include/linux/fs.h ../include/sys/types.h \ +! ../include/sys/dirent.h ../include/limits.h + inode.o : inode.c ../include/string.h ../include/sys/stat.h \ + ../include/sys/types.h ../include/linux/sched.h ../include/linux/head.h \ +! ../include/linux/fs.h ../include/sys/dirent.h ../include/limits.h \ +! ../include/linux/mm.h ../include/linux/kernel.h ../include/signal.h \ +! ../include/sys/param.h ../include/sys/time.h ../include/time.h \ +! ../include/sys/resource.h ../include/asm/system.h + ioctl.o : ioctl.c ../include/string.h ../include/errno.h \ + ../include/sys/stat.h ../include/sys/types.h ../include/linux/sched.h \ +! ../include/linux/head.h ../include/linux/fs.h ../include/sys/dirent.h \ +! ../include/limits.h ../include/linux/mm.h ../include/linux/kernel.h \ +! ../include/signal.h ../include/sys/param.h ../include/sys/time.h \ +! ../include/time.h ../include/sys/resource.h + namei.o : namei.c ../include/linux/sched.h ../include/linux/head.h \ +! ../include/linux/fs.h ../include/sys/types.h ../include/sys/dirent.h \ +! ../include/limits.h ../include/linux/mm.h ../include/linux/kernel.h \ +! ../include/signal.h ../include/sys/param.h ../include/sys/time.h \ +! ../include/time.h ../include/sys/resource.h ../include/asm/segment.h \ +! ../include/string.h ../include/fcntl.h ../include/errno.h \ +! ../include/const.h ../include/sys/stat.h + open.o : open.c ../include/string.h ../include/errno.h ../include/fcntl.h \ + ../include/sys/types.h ../include/utime.h ../include/sys/stat.h \ + ../include/linux/sched.h ../include/linux/head.h ../include/linux/fs.h \ +! ../include/sys/dirent.h ../include/limits.h ../include/linux/mm.h \ +! ../include/linux/kernel.h ../include/signal.h ../include/sys/param.h \ +! ../include/sys/time.h ../include/time.h ../include/sys/resource.h \ +! ../include/asm/segment.h + pipe.o : pipe.c ../include/signal.h ../include/sys/types.h \ + ../include/errno.h ../include/termios.h ../include/fcntl.h \ + ../include/linux/sched.h ../include/linux/head.h ../include/linux/fs.h \ +! ../include/sys/dirent.h ../include/limits.h ../include/linux/mm.h \ +! ../include/linux/kernel.h ../include/sys/param.h ../include/sys/time.h \ + ../include/time.h ../include/sys/resource.h ../include/asm/segment.h ++ read_write.o : read_write.c ../include/errno.h ../include/sys/types.h \ ++ ../include/sys/stat.h ../include/sys/dirent.h ../include/limits.h \ ++ ../include/linux/kernel.h ../include/linux/sched.h ../include/linux/head.h \ ++ ../include/linux/fs.h ../include/linux/mm.h ../include/signal.h \ ++ ../include/sys/param.h ../include/sys/time.h ../include/time.h \ ++ ../include/sys/resource.h ../include/linux/minix_fs.h \ ++ ../include/asm/segment.h + select.o : select.c ../include/linux/fs.h ../include/sys/types.h \ +! ../include/sys/dirent.h ../include/limits.h ../include/linux/kernel.h \ +! ../include/linux/tty.h ../include/termios.h ../include/linux/sched.h \ +! ../include/linux/head.h ../include/linux/mm.h ../include/signal.h \ +! ../include/sys/param.h ../include/sys/time.h ../include/time.h \ +! ../include/sys/resource.h ../include/asm/segment.h ../include/asm/system.h \ +! ../include/sys/stat.h ../include/string.h ../include/const.h \ +! ../include/errno.h + stat.o : stat.c ../include/errno.h ../include/sys/stat.h \ +! ../include/sys/types.h ../include/linux/fs.h ../include/sys/dirent.h \ +! ../include/limits.h ../include/linux/sched.h ../include/linux/head.h \ + ../include/linux/mm.h ../include/linux/kernel.h ../include/signal.h \ + ../include/sys/param.h ../include/sys/time.h ../include/time.h \ +! ../include/sys/resource.h ../include/asm/segment.h +! super.o : super.c ../include/linux/config.h ../include/linux/sched.h \ +! ../include/linux/head.h ../include/linux/fs.h ../include/sys/types.h \ +! ../include/sys/dirent.h ../include/limits.h ../include/linux/mm.h \ +! ../include/linux/kernel.h ../include/signal.h ../include/sys/param.h \ +! ../include/sys/time.h ../include/time.h ../include/sys/resource.h \ +! ../include/linux/minix_fs.h ../include/asm/system.h ../include/errno.h \ +! ../include/sys/stat.h +*** ../0.95a/linux/fs/read_write.c Tue Mar 3 00:16:10 1992 +--- linux/fs/read_write.c Fri Apr 3 20:20:36 1992 +*************** +*** 4,22 **** + * (C) 1991 Linus Torvalds + */ + +- #include + #include + #include + + #include + #include + #include + +! int sys_lseek(unsigned int fd,off_t offset, unsigned int origin) + { + struct file * file; +! int tmp; + + if (fd >= NR_OPEN || !(file=current->filp[fd]) || !(file->f_inode)) + return -EBADF; + if (origin > 2) +--- 4,37 ---- + * (C) 1991 Linus Torvalds + */ + + #include + #include ++ #include ++ #include + + #include + #include ++ #include + #include + +! int sys_readdir(unsigned int fd, struct dirent * dirent) + { + struct file * file; +! struct inode * inode; + ++ if (fd >= NR_OPEN || !(file = current->filp[fd]) || ++ !(inode = file->f_inode)) ++ return -EBADF; ++ if (file->f_op && file->f_op->readdir) ++ return file->f_op->readdir(inode,file,dirent); ++ return -EBADF; ++ } ++ ++ int sys_lseek(unsigned int fd, off_t offset, unsigned int origin) ++ { ++ struct file * file; ++ int tmp, mem_dev; ++ + if (fd >= NR_OPEN || !(file=current->filp[fd]) || !(file->f_inode)) + return -EBADF; + if (origin > 2) +*************** +*** 25,45 **** + return -ESPIPE; + if (file->f_op && file->f_op->lseek) + return file->f_op->lseek(file->f_inode,file,offset,origin); + /* this is the default handler if no lseek handler is present */ + switch (origin) { + case 0: +! if (offset<0) return -EINVAL; + file->f_pos=offset; + break; + case 1: +! if (file->f_pos+offset<0) return -EINVAL; + file->f_pos += offset; + break; + case 2: +! if ((tmp=file->f_inode->i_size+offset) < 0) + return -EINVAL; + file->f_pos = tmp; + } + return file->f_pos; + } + +--- 40,64 ---- + return -ESPIPE; + if (file->f_op && file->f_op->lseek) + return file->f_op->lseek(file->f_inode,file,offset,origin); ++ mem_dev = S_ISCHR(file->f_inode->i_mode); ++ + /* this is the default handler if no lseek handler is present */ + switch (origin) { + case 0: +! if (offset<0 && !mem_dev) return -EINVAL; + file->f_pos=offset; + break; + case 1: +! if (file->f_pos+offset<0 && !mem_dev) return -EINVAL; + file->f_pos += offset; + break; + case 2: +! if ((tmp=file->f_inode->i_size+offset)<0 && !mem_dev) + return -EINVAL; + file->f_pos = tmp; + } ++ if (mem_dev && file->f_pos < 0) ++ return 0; + return file->f_pos; + } + +*** ../0.95a/linux/fs/buffer.c Fri Mar 13 19:06:26 1992 +--- linux/fs/buffer.c Wed Apr 1 02:06:48 1992 +*************** +*** 27,34 **** + #include + + extern int end; +! struct buffer_head * start_buffer = (struct buffer_head *) &end; +! struct buffer_head * hash_table[NR_HASH]; + static struct buffer_head * free_list; + static struct task_struct * buffer_wait = NULL; + int NR_BUFFERS = 0; +--- 27,34 ---- + #include + + extern int end; +! static struct buffer_head * start_buffer = (struct buffer_head *) &end; +! static struct buffer_head * hash_table[NR_HASH]; + static struct buffer_head * free_list; + static struct task_struct * buffer_wait = NULL; + int NR_BUFFERS = 0; +*************** +*** 406,411 **** +--- 406,415 ---- + else + b = (void *) buffer_end; + while ( (b -= BLOCK_SIZE) >= ((void *) (h+1)) ) { ++ if (((unsigned long) (h+1)) > 0xA0000) { ++ printk("buffer-list doesn't fit in low meg - contact Linus\n"); ++ break; ++ } + h->b_dev = 0; + h->b_dirt = 0; + h->b_count = 0; +*** ../0.95a/linux/fs/inode.c Sat Mar 14 19:33:21 1992 +--- linux/fs/inode.c Fri Apr 3 16:09:27 1992 +*************** +*** 8,14 **** + #include + + #include +- #include + #include + #include + #include +--- 8,13 ---- +*************** +*** 15,23 **** + + struct inode inode_table[NR_INODE]={{0,},}; + +- extern void minix_read_inode(struct inode * inode); +- extern void minix_write_inode(struct inode * inode); +- + static inline void wait_on_inode(struct inode * inode) + { + cli(); +--- 14,19 ---- +*************** +*** 48,54 **** + unlock_inode(inode); + return; + } +! minix_write_inode(inode); + unlock_inode(inode); + } + +--- 44,51 ---- + unlock_inode(inode); + return; + } +! if (inode->i_op && inode->i_op->write_inode) +! inode->i_op->write_inode(inode); + unlock_inode(inode); + } + +*************** +*** 55,67 **** + static void read_inode(struct inode * inode) + { + lock_inode(inode); +! minix_read_inode(inode); + unlock_inode(inode); + } + + int bmap(struct inode * inode, int block) + { +! return minix_bmap(inode,block); + } + + void invalidate_inodes(int dev) +--- 52,77 ---- + static void read_inode(struct inode * inode) + { + lock_inode(inode); +! if (inode->i_sb && inode->i_sb->s_op && inode->i_sb->s_op->read_inode) +! inode->i_sb->s_op->read_inode(inode); + unlock_inode(inode); + } + ++ /* ++ * bmap is needed for demand-loading and paging: if this function ++ * doesn't exist for a filesystem, then those things are impossible: ++ * executables cannot be run from the filesystem etc... ++ * ++ * This isn't as bad as it sounds: the read-routines might still work, ++ * so the filesystem would be otherwise ok (for example, you might have ++ * a DOS filesystem, which doesn't lend itself to bmap very well, but ++ * you could still transfer files to/from the filesystem) ++ */ + int bmap(struct inode * inode, int block) + { +! if (inode->i_op && inode->i_op->bmap) +! return inode->i_op->bmap(inode,block); +! return 0; + } + + void invalidate_inodes(int dev) +*************** +*** 127,134 **** + return; + } + if (!inode->i_nlink) { +! minix_truncate(inode); +! minix_free_inode(inode); + return; + } + if (inode->i_dirt) { +--- 137,144 ---- + return; + } + if (!inode->i_nlink) { +! if (inode->i_op && inode->i_op->put_inode) +! inode->i_op->put_inode(inode); + return; + } + if (inode->i_dirt) { +*** ../0.95a/linux/fs/open.c Mon Mar 2 23:52:07 1992 +--- linux/fs/open.c Thu Apr 2 23:41:50 1992 +*************** +*** 29,34 **** +--- 29,39 ---- + if (!(inode=namei(filename))) + return -ENOENT; + if (times) { ++ if (current->euid != inode->i_uid && ++ !permission(inode,MAY_WRITE)) { ++ iput(inode); ++ return -EPERM; ++ } + actime = get_fs_long((unsigned long *) ×->actime); + modtime = get_fs_long((unsigned long *) ×->modtime); + } else +*** ../0.95a/linux/fs/char_dev.c Mon Mar 2 04:16:20 1992 +--- linux/fs/char_dev.c Wed Apr 1 01:26:11 1992 +*************** +*** 38,63 **** + + static int rw_mem(int rw,char * buf, int count, off_t * pos) + { +! return -EIO; + } + + static int rw_kmem(int rw,char * buf, int count, off_t * pos) + { +! /* kmem by Damiano */ +! int i = *pos; /* Current position where to read */ + +! /* i can go from 0 to LOW_MEM (See include/linux/mm.h */ +! /* I am not shure about it but it doesn't mem fault :-) */ +! while ( (count-- > 0) && (i > 20 & 0xffc); +! if (((pte = *((unsigned long *) pde)) & 1) == 0) +! return 0; /* page table not present */ +! pte &= 0xfffff000; +! pte += *pos >> 10 & 0xffc; +! if (((tmp = *((unsigned long *) pte)) & 1) == 0) +! return 0; +! if (rw == WRITE && (tmp & 2) == 0) +! un_wp_page((unsigned long *) pte); +! p = (char *) ((tmp & 0xfffff000) + (*pos & 0xfff)); +! while (1) { +! if (rw == WRITE) +! *p++ = get_fs_byte(buf++); +! else +! put_fs_byte(*p++, buf++); +! +! if (--i == 0) +! break; +! +! if (count && ((unsigned long) p & 0xfff) == 0) { +! if (((pte += 4) & 0xfff) == 0) { +! if (((pde += 4) & 0xfff) == 0) +! break; +! if (((pte = *((unsigned long *) pde)) & 1) == 0) +! break; +! pte &= 0xfffff000; +! } +! if (((tmp = *((unsigned long *) pte)) & 1) == 0) +! break; +! +! if (rw == WRITE && (tmp & 2) == 0) +! un_wp_page((unsigned long *) pte); +! p = (char *) (tmp & 0xfffff000); +! } +! } +! return(count - i); + } + + static int rw_kmem(int rw,char * buf, int count, off_t * pos) + { +! char *p=(char *) *pos; + +! if ((unsigned long) *pos > HIGH_MEMORY) +! return 0; +! if ((unsigned long) *pos + count > HIGH_MEMORY) +! count = HIGH_MEMORY - *pos; +! +! switch (rw) { +! case READ: +! while ((count -= 4) >= 0) +! put_fs_long(*((unsigned long *) p)++, +! ((unsigned long *) buf)++); +! count += 4; +! while (--count >= 0) +! put_fs_byte(*p++, buf++); +! break; +! case WRITE: +! while (--count >= 0) +! *p++ = get_fs_byte(buf++); +! break; +! default: +! return -EINVAL; + } +! p -= *pos; +! *pos += (int) p; +! return (int) p; + } + + static int rw_port(int rw,char * buf, int count, off_t * pos) +*** ../0.95a/linux/fs/exec.c Wed Mar 4 06:24:51 1992 +--- linux/fs/exec.c Wed Apr 1 01:26:36 1992 +*************** +*** 216,221 **** +--- 216,222 ---- + int retval; + int sh_bang = 0; + unsigned long p=PAGE_SIZE*MAX_ARG_PAGES-4; ++ int ch; + + if ((0xffff & eip[1]) != 0x000f) + panic("execve called from supervisor mode"); +*************** +*** 348,353 **** +--- 349,363 ---- + } + /* OK, This is the point of no return */ + /* note that current->library stays unchanged by an exec */ ++ for (i=0; (ch = get_fs_byte(filename++)) != '\0';) ++ if (ch == '/') ++ i = 0; ++ else ++ if (i < 8) ++ current->comm[i++] = ch; ++ if (i < 8) ++ current->comm[i] = '\0'; ++ + if (current->executable) + iput(current->executable); + current->executable = inode; +*************** +*** 374,379 **** +--- 384,390 ---- + (current->end_data = ex.a_data + + (current->end_code = ex.a_text)); + current->start_stack = p; ++ current->rss = (LIBRARY_OFFSET - p + PAGE_SIZE-1) / PAGE_SIZE; + current->suid = current->euid = e_uid; + current->sgid = current->egid = e_gid; + eip[0] = ex.a_entry; /* eip, magic happens :-) */ +*** ../0.95a/linux/fs/super.c Fri Feb 28 19:01:44 1992 +--- linux/fs/super.c Fri Apr 3 16:22:05 1992 +*************** +*** 29,36 **** + /* this is initialized in init/main.c */ + int ROOT_DEV = 0; + +! static void lock_super(struct super_block * sb) + { + cli(); + while (sb->s_lock) + sleep_on(&(sb->s_wait)); +--- 29,55 ---- + /* this is initialized in init/main.c */ + int ROOT_DEV = 0; + +! /* Move into include file later */ +! +! static struct file_system_type file_systems[] = { +! {minix_read_super,"minix"}, +! {NULL,NULL} +! }; +! +! /* end of include file */ +! +! struct file_system_type *get_fs_type(char *name) + { ++ int a; ++ ++ for(a = 0 ; file_systems[a].read_super ; a++) ++ if (!strcmp(name,file_systems[a].name)) ++ return(&file_systems[a]); ++ return(NULL); ++ } ++ ++ void lock_super(struct super_block * sb) ++ { + cli(); + while (sb->s_lock) + sleep_on(&(sb->s_wait)); +*************** +*** 38,44 **** + sti(); + } + +! static void free_super(struct super_block * sb) + { + cli(); + sb->s_lock = 0; +--- 57,63 ---- + sti(); + } + +! void free_super(struct super_block * sb) + { + cli(); + sb->s_lock = 0; +*************** +*** 46,52 **** + sti(); + } + +! static void wait_on_super(struct super_block * sb) + { + cli(); + while (sb->s_lock) +--- 65,71 ---- + sti(); + } + +! void wait_on_super(struct super_block * sb) + { + cli(); + while (sb->s_lock) +*************** +*** 75,81 **** + void put_super(int dev) + { + struct super_block * sb; +- int i; + + if (dev == ROOT_DEV) { + printk("root diskette changed: prepare for armageddon\n\r"); +--- 94,99 ---- +*************** +*** 87,107 **** + printk("Mounted disk changed - tssk, tssk\n\r"); + return; + } +! lock_super(sb); +! sb->s_dev = 0; +! for(i=0;is_imap[i]); +! for(i=0;is_zmap[i]); +! free_super(sb); +! return; + } + +! static struct super_block * read_super(int dev) + { + struct super_block * s; +! struct buffer_head * bh; +! int i,block; + + if (!dev) + return NULL; +--- 105,118 ---- + printk("Mounted disk changed - tssk, tssk\n\r"); + return; + } +! if (sb->s_op && sb->s_op->put_super) +! sb->s_op->put_super(sb); + } + +! static struct super_block * read_super(int dev,char *name,void *data) + { + struct super_block * s; +! struct file_system_type *type; + + if (!dev) + return NULL; +*************** +*** 108,113 **** +--- 119,128 ---- + check_disk_change(dev); + if (s = get_super(dev)) + return s; ++ if (!(type=get_fs_type(name))) { ++ printk("get fs type failed %s\n",name); ++ return NULL; ++ } + for (s = 0+super_block ;; s++) { + if (s >= NR_SUPER+super_block) + return NULL; +*************** +*** 115,167 **** + break; + } + s->s_dev = dev; +! s->s_mounted = NULL; + s->s_covered = NULL; + s->s_time = 0; + s->s_rd_only = 0; + s->s_dirt = 0; +! lock_super(s); +! if (!(bh = bread(dev,1))) { +! s->s_dev=0; +! free_super(s); +! return NULL; +! } +! *((struct minix_super_block *) s) = +! *((struct minix_super_block *) bh->b_data); +! brelse(bh); +! if (s->s_magic != MINIX_SUPER_MAGIC) { +! s->s_dev = 0; +! free_super(s); +! return NULL; +! } +! for (i=0;i < MINIX_I_MAP_SLOTS;i++) +! s->s_imap[i] = NULL; +! for (i=0;i < MINIX_Z_MAP_SLOTS;i++) +! s->s_zmap[i] = NULL; +! block=2; +! for (i=0 ; i < s->s_imap_blocks ; i++) +! if (s->s_imap[i]=bread(dev,block)) +! block++; +! else +! break; +! for (i=0 ; i < s->s_zmap_blocks ; i++) +! if (s->s_zmap[i]=bread(dev,block)) +! block++; +! else +! break; +! if (block != 2+s->s_imap_blocks+s->s_zmap_blocks) { +! for(i=0;is_imap[i]); +! for(i=0;is_zmap[i]); +! s->s_dev=0; +! free_super(s); +! return NULL; +! } +! s->s_imap[0]->b_data[0] |= 1; +! s->s_zmap[0]->b_data[0] |= 1; +! free_super(s); +! return s; + } + + int sys_umount(char * dev_name) +--- 130,143 ---- + break; + } + s->s_dev = dev; +! if (!type->read_super(s,data)) +! return(NULL); +! s->s_dev = dev; + s->s_covered = NULL; + s->s_time = 0; + s->s_rd_only = 0; + s->s_dirt = 0; +! return(s); + } + + int sys_umount(char * dev_name) +*************** +*** 184,190 **** + return -ENOENT; + if (!sb->s_covered->i_mount) + printk("Mounted inode has i_mount=0\n"); +! for (inode=inode_table+0 ; inodei_dev==dev && inode->i_count) + if (inode == sb->s_mounted && inode->i_count == 1) + continue; +--- 160,166 ---- + return -ENOENT; + if (!sb->s_covered->i_mount) + printk("Mounted inode has i_mount=0\n"); +! for (inode = inode_table+0 ; inode < inode_table+NR_INODE ; inode++) + if (inode->i_dev==dev && inode->i_count) + if (inode == sb->s_mounted && inode->i_count == 1) + continue; +*************** +*** 195,202 **** + sb->s_covered = NULL; + iput(sb->s_mounted); + sb->s_mounted = NULL; +! put_super(dev); +! sync_dev(dev); + return 0; + } + +--- 171,178 ---- + sb->s_covered = NULL; + iput(sb->s_mounted); + sb->s_mounted = NULL; +! put_super(dev); +! sync_dev(dev); + return 0; + } + +*************** +*** 224,231 **** + iput(dir_i); + return -EPERM; + } +! if (!(sb=read_super(dev))) { + iput(dir_i); + return -EBUSY; + } + if (sb->s_covered) { +--- 200,211 ---- + iput(dir_i); + return -EPERM; + } +! if (dir_i->i_mount) { + iput(dir_i); ++ return -EPERM; ++ } ++ if (!(sb=read_super(dev,"minix",NULL))) { ++ iput(dir_i); + return -EBUSY; + } + if (sb->s_covered) { +*************** +*** 232,248 **** + iput(dir_i); + return -EBUSY; + } +! if (dir_i->i_mount) { +! iput(dir_i); +! return -EPERM; +! } +! if (!(sb->s_mounted = iget(dev,MINIX_ROOT_INO))) { +! iput(dir_i); +! return -EPERM; +! } +! sb->s_covered=dir_i; +! dir_i->i_mount=1; +! dir_i->i_dirt=1; /* NOTE! we don't iput(dir_i) */ + return 0; /* we do that in umount */ + } + +--- 212,220 ---- + iput(dir_i); + return -EBUSY; + } +! sb->s_covered = dir_i; +! dir_i->i_mount = 1; +! dir_i->i_dirt = 1; /* NOTE! we don't iput(dir_i) */ + return 0; /* we do that in umount */ + } + +*************** +*** 265,274 **** + p->s_lock = 0; + p->s_wait = NULL; + } +! if (!(p=read_super(ROOT_DEV))) + panic("Unable to mount root"); + if (!(mi=iget(ROOT_DEV,MINIX_ROOT_INO))) + panic("Unable to read root i-node"); + mi->i_count += 3 ; /* NOTE! it is logically used 4 times, not 1 */ + p->s_mounted = p->s_covered = mi; + current->pwd = mi; +--- 237,249 ---- + p->s_lock = 0; + p->s_wait = NULL; + } +! if (!(p=read_super(ROOT_DEV,"minix",NULL))) + panic("Unable to mount root"); ++ /*wait_for_keypress(); + if (!(mi=iget(ROOT_DEV,MINIX_ROOT_INO))) + panic("Unable to read root i-node"); ++ wait_for_keypress();*/ ++ mi=p->s_mounted; + mi->i_count += 3 ; /* NOTE! it is logically used 4 times, not 1 */ + p->s_mounted = p->s_covered = mi; + current->pwd = mi; +*** ../0.95a/linux/fs/namei.c Fri Mar 6 19:04:09 1992 +--- linux/fs/namei.c Fri Apr 3 16:15:56 1992 +*************** +*** 9,15 **** + */ + + #include +- #include + #include + #include + +--- 9,14 ---- +*************** +*** 249,255 **** + } + inode->i_atime = CURRENT_TIME; + if (flag & O_TRUNC) +! minix_truncate(inode); + *res_inode = inode; + return 0; + } +--- 248,255 ---- + } + inode->i_atime = CURRENT_TIME; + if (flag & O_TRUNC) +! if (inode->i_op && inode->i_op->truncate) +! inode->i_op->truncate(inode); + *res_inode = inode; + return 0; + } +*************** +*** 270,276 **** + } + if (!permission(dir,MAY_WRITE)) { + iput(dir); +! return -EPERM; + } + if (!dir->i_op || !dir->i_op->mknod) { + iput(dir); +--- 270,276 ---- + } + if (!permission(dir,MAY_WRITE)) { + iput(dir); +! return -EACCES; + } + if (!dir->i_op || !dir->i_op->mknod) { + iput(dir); +*************** +*** 293,299 **** + } + if (!permission(dir,MAY_WRITE)) { + iput(dir); +! return -EPERM; + } + if (!dir->i_op || !dir->i_op->mkdir) { + iput(dir); +--- 293,299 ---- + } + if (!permission(dir,MAY_WRITE)) { + iput(dir); +! return -EACCES; + } + if (!dir->i_op || !dir->i_op->mkdir) { + iput(dir); +*************** +*** 316,322 **** + } + if (!permission(dir,MAY_WRITE)) { + iput(dir); +! return -EPERM; + } + if (!dir->i_op || !dir->i_op->rmdir) { + iput(dir); +--- 316,322 ---- + } + if (!permission(dir,MAY_WRITE)) { + iput(dir); +! return -EACCES; + } + if (!dir->i_op || !dir->i_op->rmdir) { + iput(dir); +*************** +*** 335,345 **** + return -ENOENT; + if (!namelen) { + iput(dir); +! return -ENOENT; + } + if (!permission(dir,MAY_WRITE)) { + iput(dir); +! return -EPERM; + } + if (!dir->i_op || !dir->i_op->unlink) { + iput(dir); +--- 335,345 ---- + return -ENOENT; + if (!namelen) { + iput(dir); +! return -EPERM; + } + if (!permission(dir,MAY_WRITE)) { + iput(dir); +! return -EACCES; + } + if (!dir->i_op || !dir->i_op->unlink) { + iput(dir); +*************** +*** 356,369 **** + + dir = dir_namei(newname,&namelen,&basename, NULL); + if (!dir) +! return -EACCES; + if (!namelen) { + iput(dir); +! return -EPERM; + } + if (!permission(dir,MAY_WRITE)) { + iput(dir); +! return -EPERM; + } + if (!dir->i_op || !dir->i_op->symlink) { + iput(dir); +--- 356,369 ---- + + dir = dir_namei(newname,&namelen,&basename, NULL); + if (!dir) +! return -ENOENT; + if (!namelen) { + iput(dir); +! return -ENOENT; + } + if (!permission(dir,MAY_WRITE)) { + iput(dir); +! return -EACCES; + } + if (!dir->i_op || !dir->i_op->symlink) { + iput(dir); +*** ../0.95a/linux/fs/ioctl.c Thu Feb 20 17:01:12 1992 +--- linux/fs/ioctl.c Tue Mar 31 20:52:08 1992 +*************** +*** 10,15 **** +--- 10,16 ---- + + #include + ++ extern int hd_ioctl(int dev, int cmd, int arg); + extern int tty_ioctl(int dev, int cmd, int arg); + extern int pipe_ioctl(struct inode *pino, int cmd, int arg); + +*************** +*** 21,27 **** + NULL, /* nodev */ + NULL, /* /dev/mem */ + NULL, /* /dev/fd */ +! NULL, /* /dev/hd */ + tty_ioctl, /* /dev/ttyx */ + tty_ioctl, /* /dev/tty */ + NULL, /* /dev/lp */ +--- 22,28 ---- + NULL, /* nodev */ + NULL, /* /dev/mem */ + NULL, /* /dev/fd */ +! hd_ioctl, /* /dev/hd */ + tty_ioctl, /* /dev/ttyx */ + tty_ioctl, /* /dev/tty */ + NULL, /* /dev/lp */ +*** ../0.95a/linux/fs/pipe.c Fri Mar 6 15:04:16 1992 +--- linux/fs/pipe.c Fri Mar 27 11:18:57 1992 +*************** +*** 41,47 **** + put_fs_byte(((char *)inode->i_size)[size++],buf++); + } + wake_up(& PIPE_WRITE_WAIT(*inode)); +! return read; + } + + int pipe_write(struct inode * inode, struct file * filp, char * buf, int count) +--- 41,47 ---- + put_fs_byte(((char *)inode->i_size)[size++],buf++); + } + wake_up(& PIPE_WRITE_WAIT(*inode)); +! return read?read:-EAGAIN; + } + + int pipe_write(struct inode * inode, struct file * filp, char * buf, int count) +*** ../0.95a/linux/fs/minix/Makefile Thu Mar 5 23:36:47 1992 +--- linux/fs/minix/Makefile Sat Apr 4 17:33:13 1992 +*************** +*** 1,10 **** + AR =ar + AS =as +- CC =gcc + LD =ld +! CFLAGS =-Wall -O -fstrength-reduce -fomit-frame-pointer \ +! -nostdinc -I../../include +! CPP =gcc -E -nostdinc -I../../include + + .c.s: + $(CC) $(CFLAGS) \ +--- 1,17 ---- ++ # ++ # Makefile for the linux minix-filesystem routines. ++ # ++ # Note! Dependencies are done automagically by 'make dep', which also ++ # removes any old dependencies. DON'T put your own dependencies here ++ # unless it's something special (ie not a .c file). ++ # ++ # Note 2! The CFLAGS definitions are now in the main makefile... ++ + AR =ar + AS =as + LD =ld +! CC =gcc -nostdinc -I../../include +! CPP =cpp -nostdinc -I../../include + + .c.s: + $(CC) $(CFLAGS) \ +*************** +*** 32,43 **** + ### Dependencies: + bitmap.o : bitmap.c ../../include/string.h ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/sys/types.h ../../include/linux/mm.h \ +! ../../include/linux/kernel.h ../../include/signal.h \ +! ../../include/sys/param.h ../../include/sys/time.h ../../include/time.h \ +! ../../include/sys/resource.h ../../include/linux/minix_fs.h + file_dev.o : file_dev.c ../../include/errno.h ../../include/fcntl.h \ +! ../../include/sys/types.h ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ + ../../include/linux/mm.h ../../include/linux/kernel.h \ + ../../include/signal.h ../../include/sys/param.h ../../include/sys/time.h \ +--- 39,52 ---- + ### Dependencies: + bitmap.o : bitmap.c ../../include/string.h ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/sys/types.h ../../include/sys/dirent.h ../../include/limits.h \ +! ../../include/linux/mm.h ../../include/linux/kernel.h \ +! ../../include/signal.h ../../include/sys/param.h ../../include/sys/time.h \ +! ../../include/time.h ../../include/sys/resource.h \ +! ../../include/linux/minix_fs.h + file_dev.o : file_dev.c ../../include/errno.h ../../include/fcntl.h \ +! ../../include/sys/types.h ../../include/sys/dirent.h ../../include/limits.h \ +! ../../include/sys/stat.h ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ + ../../include/linux/mm.h ../../include/linux/kernel.h \ + ../../include/signal.h ../../include/sys/param.h ../../include/sys/time.h \ +*************** +*** 46,59 **** + inode.o : inode.c ../../include/string.h ../../include/sys/stat.h \ + ../../include/sys/types.h ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/linux/mm.h ../../include/linux/kernel.h \ +! ../../include/signal.h ../../include/sys/param.h ../../include/sys/time.h \ +! ../../include/time.h ../../include/sys/resource.h \ +! ../../include/linux/minix_fs.h ../../include/asm/system.h + minix_op.o : minix_op.c ../../include/linux/fs.h ../../include/sys/types.h \ + ../../include/linux/minix_fs.h + namei.o : namei.c ../../include/linux/sched.h ../../include/linux/head.h \ +! ../../include/linux/fs.h ../../include/sys/types.h ../../include/linux/mm.h \ + ../../include/linux/kernel.h ../../include/signal.h \ + ../../include/sys/param.h ../../include/sys/time.h ../../include/time.h \ + ../../include/sys/resource.h ../../include/linux/minix_fs.h \ +--- 55,71 ---- + inode.o : inode.c ../../include/string.h ../../include/sys/stat.h \ + ../../include/sys/types.h ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/sys/dirent.h ../../include/limits.h ../../include/linux/mm.h \ +! ../../include/linux/kernel.h ../../include/signal.h \ +! ../../include/sys/param.h ../../include/sys/time.h ../../include/time.h \ +! ../../include/sys/resource.h ../../include/linux/minix_fs.h \ +! ../../include/asm/system.h + minix_op.o : minix_op.c ../../include/linux/fs.h ../../include/sys/types.h \ ++ ../../include/sys/dirent.h ../../include/limits.h \ + ../../include/linux/minix_fs.h + namei.o : namei.c ../../include/linux/sched.h ../../include/linux/head.h \ +! ../../include/linux/fs.h ../../include/sys/types.h \ +! ../../include/sys/dirent.h ../../include/limits.h ../../include/linux/mm.h \ + ../../include/linux/kernel.h ../../include/signal.h \ + ../../include/sys/param.h ../../include/sys/time.h ../../include/time.h \ + ../../include/sys/resource.h ../../include/linux/minix_fs.h \ +*************** +*** 61,69 **** + ../../include/errno.h ../../include/const.h ../../include/sys/stat.h + truncate.o : truncate.c ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/sys/types.h ../../include/linux/mm.h \ +! ../../include/linux/kernel.h ../../include/signal.h \ +! ../../include/sys/param.h ../../include/sys/time.h ../../include/time.h \ +! ../../include/sys/resource.h ../../include/linux/minix_fs.h \ +! ../../include/linux/tty.h ../../include/termios.h ../../include/errno.h \ +! ../../include/fcntl.h ../../include/sys/stat.h +--- 73,82 ---- + ../../include/errno.h ../../include/const.h ../../include/sys/stat.h + truncate.o : truncate.c ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/sys/types.h ../../include/sys/dirent.h ../../include/limits.h \ +! ../../include/linux/mm.h ../../include/linux/kernel.h \ +! ../../include/signal.h ../../include/sys/param.h ../../include/sys/time.h \ +! ../../include/time.h ../../include/sys/resource.h \ +! ../../include/linux/minix_fs.h ../../include/linux/tty.h \ +! ../../include/termios.h ../../include/errno.h ../../include/fcntl.h \ +! ../../include/sys/stat.h +*** ../0.95a/linux/fs/minix/inode.c Mon Mar 2 01:15:17 1992 +--- linux/fs/minix/inode.c Fri Apr 3 16:20:06 1992 +*************** +*** 13,27 **** + #include + #include + +! static int _bmap(struct inode * inode,int block,int create) + { + struct buffer_head * bh; + int i; + +! if (block<0) +! panic("_bmap: block<0"); +! if (block >= 7+512+512*512) +! panic("_bmap: block>big"); + if (block<7) { + if (create && !inode->i_data[block]) + if (inode->i_data[block]=minix_new_block(inode->i_dev)) { +--- 13,112 ---- + #include + #include + +! int sync_dev(int dev); +! +! void minix_put_super(struct super_block *sb) + { ++ int i; ++ ++ lock_super(sb); ++ sb->s_dev = 0; ++ for(i = 0 ; i < MINIX_I_MAP_SLOTS ; i++) ++ brelse(sb->s_imap[i]); ++ for(i = 0 ; i < MINIX_Z_MAP_SLOTS ; i++) ++ brelse(sb->s_zmap[i]); ++ free_super(sb); ++ return; ++ } ++ ++ static struct super_operations minix_sops = { ++ minix_read_inode, ++ minix_put_super ++ }; ++ ++ struct super_block *minix_read_super(struct super_block *s,void *data) ++ { ++ struct buffer_head *bh; ++ int i,dev=s->s_dev,block; ++ ++ lock_super(s); ++ if (!(bh = bread(dev,1))) { ++ s->s_dev=0; ++ free_super(s); ++ printk("bread failed\n"); ++ return NULL; ++ } ++ *((struct minix_super_block *) s) = ++ *((struct minix_super_block *) bh->b_data); ++ brelse(bh); ++ if (s->s_magic != MINIX_SUPER_MAGIC) { ++ s->s_dev = 0; ++ free_super(s); ++ printk("magic match failed\n"); ++ return NULL; ++ } ++ for (i=0;i < MINIX_I_MAP_SLOTS;i++) ++ s->s_imap[i] = NULL; ++ for (i=0;i < MINIX_Z_MAP_SLOTS;i++) ++ s->s_zmap[i] = NULL; ++ block=2; ++ for (i=0 ; i < s->s_imap_blocks ; i++) ++ if (s->s_imap[i]=bread(dev,block)) ++ block++; ++ else ++ break; ++ for (i=0 ; i < s->s_zmap_blocks ; i++) ++ if (s->s_zmap[i]=bread(dev,block)) ++ block++; ++ else ++ break; ++ if (block != 2+s->s_imap_blocks+s->s_zmap_blocks) { ++ for(i=0;is_imap[i]); ++ for(i=0;is_zmap[i]); ++ s->s_dev=0; ++ free_super(s); ++ printk("block failed\n"); ++ return NULL; ++ } ++ s->s_imap[0]->b_data[0] |= 1; ++ s->s_zmap[0]->b_data[0] |= 1; ++ free_super(s); ++ /* set up enough so that it can read an inode */ ++ s->s_dev = dev; ++ s->s_op = &minix_sops; ++ if (!(s->s_mounted = iget(dev,MINIX_ROOT_INO))) { ++ s->s_dev=0; ++ printk("get root inode failed\n"); ++ return NULL; ++ } ++ return s; ++ } ++ ++ static int _minix_bmap(struct inode * inode,int block,int create) ++ { + struct buffer_head * bh; + int i; + +! if (block<0) { +! printk("_minix_bmap: block<0"); +! return 0; +! } +! if (block >= 7+512+512*512) { +! printk("_minix_bmap: block>big"); +! return 0; +! } + if (block<7) { + if (create && !inode->i_data[block]) + if (inode->i_data[block]=minix_new_block(inode->i_dev)) { +*************** +*** 83,94 **** + + int minix_bmap(struct inode * inode,int block) + { +! return _bmap(inode,block,0); + } + + int minix_create_block(struct inode * inode, int block) + { +! return _bmap(inode,block,1); + } + + void minix_read_inode(struct inode * inode) +--- 168,179 ---- + + int minix_bmap(struct inode * inode,int block) + { +! return _minix_bmap(inode,block,0); + } + + int minix_create_block(struct inode * inode, int block) + { +! return _minix_bmap(inode,block,1); + } + + void minix_read_inode(struct inode * inode) +*** ../0.95a/linux/fs/minix/namei.c Tue Mar 3 19:39:35 1992 +--- linux/fs/minix/namei.c Fri Apr 3 16:11:22 1992 +*************** +*** 15,24 **** + #include + #include + +- extern int permission(struct inode * inode,int mask); +- extern struct inode * _namei(const char * filename, struct inode * base, +- int follow_links); +- + /* + * comment out this line if you want names > MINIX_NAME_LEN chars to be + * truncated. Else they will be disallowed. +--- 15,20 ---- +*************** +*** 89,95 **** + if ((char *)de >= BLOCK_SIZE+bh->b_data) { + brelse(bh); + bh = NULL; +! if (!(block = bmap(dir,i/MINIX_DIR_ENTRIES_PER_BLOCK)) || + !(bh = bread(dir->i_dev,block))) { + i += MINIX_DIR_ENTRIES_PER_BLOCK; + continue; +--- 85,91 ---- + if ((char *)de >= BLOCK_SIZE+bh->b_data) { + brelse(bh); + bh = NULL; +! if (!(block = minix_bmap(dir,i/MINIX_DIR_ENTRIES_PER_BLOCK)) || + !(bh = bread(dir->i_dev,block))) { + i += MINIX_DIR_ENTRIES_PER_BLOCK; + continue; +*************** +*** 398,404 **** + while (nr= (void *) (bh->b_data+BLOCK_SIZE)) { + brelse(bh); +! block=bmap(inode,nr/MINIX_DIR_ENTRIES_PER_BLOCK); + if (!block) { + nr += MINIX_DIR_ENTRIES_PER_BLOCK; + continue; +--- 394,400 ---- + while (nr= (void *) (bh->b_data+BLOCK_SIZE)) { + brelse(bh); +! block = minix_bmap(inode,nr/MINIX_DIR_ENTRIES_PER_BLOCK); + if (!block) { + nr += MINIX_DIR_ENTRIES_PER_BLOCK; + continue; +*** ../0.95a/linux/fs/minix/minix_op.c Tue Mar 3 00:18:39 1992 +--- linux/fs/minix/minix_op.c Fri Apr 3 20:19:03 1992 +*************** +*** 7,12 **** +--- 7,18 ---- + #include + #include + ++ void minix_put_inode(struct inode *inode) ++ { ++ minix_truncate(inode); ++ minix_free_inode(inode); ++ } ++ + /* + * These are the low-level inode operations for minix filesystem inodes. + */ +*************** +*** 23,38 **** + minix_readlink, + minix_open, + minix_release, +! minix_follow_link + }; + + /* +! * We have just NULL's here: the current defaults are ok for + * the minix filesystem. + */ + struct file_operations minix_file_operations = { + NULL, /* lseek */ + NULL, /* read */ +! NULL /* write */ + }; + +--- 29,49 ---- + minix_readlink, + minix_open, + minix_release, +! minix_follow_link, +! minix_bmap, +! minix_truncate, +! minix_write_inode, +! minix_put_inode + }; + + /* +! * We have mostly NULL's here: the current defaults are ok for + * the minix filesystem. + */ + struct file_operations minix_file_operations = { + NULL, /* lseek */ + NULL, /* read */ +! NULL, /* write */ +! minix_readdir + }; + +*** ../0.95a/linux/fs/minix/file_dev.c Tue Mar 17 03:41:53 1992 +--- linux/fs/minix/file_dev.c Fri Apr 3 21:35:21 1992 +*************** +*** 6,11 **** +--- 6,13 ---- + + #include + #include ++ #include ++ #include + + #include + #include +*************** +*** 15,20 **** +--- 17,64 ---- + #define MIN(a,b) (((a)<(b))?(a):(b)) + #define MAX(a,b) (((a)>(b))?(a):(b)) + ++ int minix_readdir(struct inode * inode, struct file * filp, struct dirent * dirent) ++ { ++ unsigned int block,offset,i; ++ char c; ++ struct buffer_head * bh; ++ struct minix_dir_entry * de; ++ ++ if (!S_ISDIR(inode->i_mode)) ++ return -EBADF; ++ if (filp->f_pos & 15) ++ return -EBADF; ++ while (filp->f_pos < inode->i_size) { ++ offset = filp->f_pos & 1023; ++ block = minix_bmap(inode,(filp->f_pos)>>BLOCK_SIZE_BITS); ++ if (!block || !(bh = bread(inode->i_dev,block))) { ++ filp->f_pos += 1024-offset; ++ continue; ++ } ++ de = (struct minix_dir_entry *) (offset + bh->b_data); ++ while (offset < 1024 && filp->f_pos < inode->i_size) { ++ offset += 16; ++ filp->f_pos += 16; ++ if (de->inode) { ++ for (i = 0; i < 14; i++) ++ if (c = de->name[i]) ++ put_fs_byte(c,i+dirent->d_name); ++ else ++ break; ++ if (i) { ++ put_fs_long(de->inode,&dirent->d_ino); ++ put_fs_byte(0,i+dirent->d_name); ++ put_fs_word(i,&dirent->d_reclen); ++ return i; ++ } ++ } ++ de++; ++ } ++ brelse(bh); ++ } ++ return 0; ++ } ++ + int minix_file_read(struct inode * inode, struct file * filp, char * buf, int count) + { + int read,left,chars,nr; +*************** +*** 28,34 **** + left = count; + read = 0; + while (left > 0) { +! if (nr = bmap(inode,(filp->f_pos)>>BLOCK_SIZE_BITS)) { + if (!(bh=bread(inode->i_dev,nr))) + return read?read:-EIO; + } else +--- 72,78 ---- + left = count; + read = 0; + while (left > 0) { +! if (nr = minix_bmap(inode,(filp->f_pos)>>BLOCK_SIZE_BITS)) { + if (!(bh=bread(inode->i_dev,nr))) + return read?read:-EIO; + } else +*************** +*** 98,104 **** + if (!(filp->f_flags & O_APPEND)) { + filp->f_pos = pos; + inode->i_ctime = CURRENT_TIME; +- inode->i_dirt = 1; + } + return written; + } +--- 142,148 ---- + if (!(filp->f_flags & O_APPEND)) { + filp->f_pos = pos; + inode->i_ctime = CURRENT_TIME; + } ++ inode->i_dirt = 1; + return written; + } +*** ../0.95a/linux/kernel/Makefile Thu Mar 5 23:36:55 1992 +--- linux/kernel/Makefile Sat Apr 4 17:33:20 1992 +*************** +*** 5,23 **** + # removes any old dependencies. DON'T put your own dependencies here + # unless it's something special (ie not a .c file). + # + +- # gcc2 doesn't have these: +- #GCC_OPT = -fcombine-regs +- + AR =ar + AS =as + LD =ld + LDFLAGS =-s -x +! CC =gcc +! CFLAGS =-Wall -O -fstrength-reduce -fomit-frame-pointer $(GCC_OPT) \ +! -finline-functions -nostdinc -I../include +! CPP =gcc -E -nostdinc -I../include + + .c.s: + $(CC) $(CFLAGS) \ + -S -o $*.s $< +--- 5,20 ---- + # removes any old dependencies. DON'T put your own dependencies here + # unless it's something special (ie not a .c file). + # ++ # Note 2! The CFLAGS definitions are now in the main makefile... + + AR =ar + AS =as + LD =ld + LDFLAGS =-s -x +! CC =gcc -nostdinc -I../include +! CPP =cpp -nostdinc -I../include + ++ + .c.s: + $(CC) $(CFLAGS) \ + -S -o $*.s $< +*************** +*** 35,40 **** +--- 32,40 ---- + $(LD) -r -o kernel.o $(OBJS) + sync + ++ sched.o: sched.c ++ $(CC) $(CFLAGS) -fno-omit-frame-pointer -c $< ++ + clean: + rm -f core *.o *.a tmp_make keyboard.s + for i in *.c;do rm -f `basename $$i .c`.s;done +*************** +*** 53,103 **** + ### Dependencies: + exit.s exit.o : exit.c ../include/errno.h ../include/signal.h \ + ../include/sys/types.h ../include/sys/wait.h ../include/linux/sched.h \ +! ../include/linux/head.h ../include/linux/fs.h ../include/linux/mm.h \ +! ../include/linux/kernel.h ../include/sys/param.h ../include/sys/time.h \ +! ../include/time.h ../include/sys/resource.h ../include/linux/tty.h \ +! ../include/termios.h ../include/asm/segment.h + fork.s fork.o : fork.c ../include/errno.h ../include/linux/sched.h \ + ../include/linux/head.h ../include/linux/fs.h ../include/sys/types.h \ +! ../include/linux/mm.h ../include/linux/kernel.h ../include/signal.h \ +! ../include/sys/param.h ../include/sys/time.h ../include/time.h \ +! ../include/sys/resource.h ../include/asm/segment.h ../include/asm/system.h + mktime.s mktime.o : mktime.c ../include/time.h + panic.s panic.o : panic.c ../include/linux/kernel.h ../include/linux/sched.h \ + ../include/linux/head.h ../include/linux/fs.h ../include/sys/types.h \ +! ../include/linux/mm.h ../include/signal.h ../include/sys/param.h \ +! ../include/sys/time.h ../include/time.h ../include/sys/resource.h + printk.s printk.o : printk.c ../include/stdarg.h ../include/stddef.h \ + ../include/linux/kernel.h + ptrace.s ptrace.o : ptrace.c ../include/linux/head.h ../include/linux/kernel.h \ + ../include/linux/sched.h ../include/linux/fs.h ../include/sys/types.h \ +! ../include/linux/mm.h ../include/signal.h ../include/sys/param.h \ +! ../include/sys/time.h ../include/time.h ../include/sys/resource.h \ +! ../include/errno.h ../include/asm/segment.h ../include/asm/system.h \ +! ../include/sys/ptrace.h + sched.s sched.o : sched.c ../include/linux/sched.h ../include/linux/head.h \ +! ../include/linux/fs.h ../include/sys/types.h ../include/linux/mm.h \ +! ../include/linux/kernel.h ../include/signal.h ../include/sys/param.h \ +! ../include/sys/time.h ../include/time.h ../include/sys/resource.h \ +! ../include/linux/timer.h ../include/linux/sys.h ../include/linux/fdreg.h \ +! ../include/asm/system.h ../include/asm/io.h ../include/asm/segment.h \ +! ../include/errno.h + signal.s signal.o : signal.c ../include/linux/sched.h ../include/linux/head.h \ +! ../include/linux/fs.h ../include/sys/types.h ../include/linux/mm.h \ +! ../include/linux/kernel.h ../include/signal.h ../include/sys/param.h \ +! ../include/sys/time.h ../include/time.h ../include/sys/resource.h \ +! ../include/asm/segment.h ../include/sys/wait.h ../include/errno.h + sys.s sys.o : sys.c ../include/errno.h ../include/linux/sched.h \ + ../include/linux/head.h ../include/linux/fs.h ../include/sys/types.h \ +! ../include/linux/mm.h ../include/linux/kernel.h ../include/signal.h \ +! ../include/sys/param.h ../include/sys/time.h ../include/time.h \ +! ../include/sys/resource.h ../include/linux/tty.h ../include/termios.h \ +! ../include/linux/config.h ../include/asm/segment.h ../include/sys/times.h \ +! ../include/sys/utsname.h ../include/string.h + traps.s traps.o : traps.c ../include/string.h ../include/linux/head.h \ + ../include/linux/sched.h ../include/linux/fs.h ../include/sys/types.h \ +! ../include/linux/mm.h ../include/linux/kernel.h ../include/signal.h \ +! ../include/sys/param.h ../include/sys/time.h ../include/time.h \ +! ../include/sys/resource.h ../include/asm/system.h ../include/asm/segment.h \ +! ../include/asm/io.h ../include/errno.h + vsprintf.s vsprintf.o : vsprintf.c ../include/stdarg.h ../include/string.h +--- 53,109 ---- + ### Dependencies: + exit.s exit.o : exit.c ../include/errno.h ../include/signal.h \ + ../include/sys/types.h ../include/sys/wait.h ../include/linux/sched.h \ +! ../include/linux/head.h ../include/linux/fs.h ../include/sys/dirent.h \ +! ../include/limits.h ../include/linux/mm.h ../include/linux/kernel.h \ +! ../include/sys/param.h ../include/sys/time.h ../include/time.h \ +! ../include/sys/resource.h ../include/linux/tty.h ../include/termios.h \ +! ../include/asm/segment.h + fork.s fork.o : fork.c ../include/errno.h ../include/linux/sched.h \ + ../include/linux/head.h ../include/linux/fs.h ../include/sys/types.h \ +! ../include/sys/dirent.h ../include/limits.h ../include/linux/mm.h \ +! ../include/linux/kernel.h ../include/signal.h ../include/sys/param.h \ +! ../include/sys/time.h ../include/time.h ../include/sys/resource.h \ +! ../include/asm/segment.h ../include/asm/system.h + mktime.s mktime.o : mktime.c ../include/time.h + panic.s panic.o : panic.c ../include/linux/kernel.h ../include/linux/sched.h \ + ../include/linux/head.h ../include/linux/fs.h ../include/sys/types.h \ +! ../include/sys/dirent.h ../include/limits.h ../include/linux/mm.h \ +! ../include/signal.h ../include/sys/param.h ../include/sys/time.h \ +! ../include/time.h ../include/sys/resource.h + printk.s printk.o : printk.c ../include/stdarg.h ../include/stddef.h \ + ../include/linux/kernel.h + ptrace.s ptrace.o : ptrace.c ../include/linux/head.h ../include/linux/kernel.h \ + ../include/linux/sched.h ../include/linux/fs.h ../include/sys/types.h \ +! ../include/sys/dirent.h ../include/limits.h ../include/linux/mm.h \ +! ../include/signal.h ../include/sys/param.h ../include/sys/time.h \ +! ../include/time.h ../include/sys/resource.h ../include/errno.h \ +! ../include/asm/segment.h ../include/asm/system.h ../include/sys/ptrace.h + sched.s sched.o : sched.c ../include/linux/sched.h ../include/linux/head.h \ +! ../include/linux/fs.h ../include/sys/types.h ../include/sys/dirent.h \ +! ../include/limits.h ../include/linux/mm.h ../include/linux/kernel.h \ +! ../include/signal.h ../include/sys/param.h ../include/sys/time.h \ +! ../include/time.h ../include/sys/resource.h ../include/linux/timer.h \ +! ../include/linux/sys.h ../include/linux/fdreg.h ../include/asm/system.h \ +! ../include/asm/io.h ../include/asm/segment.h ../include/errno.h + signal.s signal.o : signal.c ../include/linux/sched.h ../include/linux/head.h \ +! ../include/linux/fs.h ../include/sys/types.h ../include/sys/dirent.h \ +! ../include/limits.h ../include/linux/mm.h ../include/linux/kernel.h \ +! ../include/signal.h ../include/sys/param.h ../include/sys/time.h \ +! ../include/time.h ../include/sys/resource.h ../include/asm/segment.h \ +! ../include/sys/wait.h ../include/errno.h + sys.s sys.o : sys.c ../include/errno.h ../include/linux/sched.h \ + ../include/linux/head.h ../include/linux/fs.h ../include/sys/types.h \ +! ../include/sys/dirent.h ../include/limits.h ../include/linux/mm.h \ +! ../include/linux/kernel.h ../include/signal.h ../include/sys/param.h \ +! ../include/sys/time.h ../include/time.h ../include/sys/resource.h \ +! ../include/linux/tty.h ../include/termios.h ../include/linux/config.h \ +! ../include/asm/segment.h ../include/sys/times.h ../include/sys/utsname.h \ +! ../include/string.h + traps.s traps.o : traps.c ../include/string.h ../include/linux/head.h \ + ../include/linux/sched.h ../include/linux/fs.h ../include/sys/types.h \ +! ../include/sys/dirent.h ../include/limits.h ../include/linux/mm.h \ +! ../include/linux/kernel.h ../include/signal.h ../include/sys/param.h \ +! ../include/sys/time.h ../include/time.h ../include/sys/resource.h \ +! ../include/asm/system.h ../include/asm/segment.h ../include/asm/io.h \ +! ../include/errno.h + vsprintf.s vsprintf.o : vsprintf.c ../include/stdarg.h ../include/string.h +*** ../0.95a/linux/kernel/sched.c Sat Mar 14 16:55:48 1992 +--- linux/kernel/sched.c Tue Mar 24 00:57:35 1992 +*************** +*** 46,57 **** + + void show_state(void) + { + int i; + + printk("\rTask-info:\n\r"); +! for (i=0;istate == TASK_INTERRUPTIBLE || p->state == TASK_RUNNING) + p->state = TASK_STOPPED; +- +- if (p == current) +- schedule(); + } + return 0; + } +--- 48,53 ---- +*************** +*** 218,232 **** + int sys_kill(int pid,int sig) + { + struct task_struct **p = NR_TASKS + task; +! int err, retval = 0; + + if (!pid) +! return(kill_pg(current->pid,sig,0)); + if (pid == -1) { + while (--p > &FIRST_TASK) +! if (err = send_sig(sig,*p,0)) +! retval = err; +! return(retval); + } + if (pid < 0) + return(kill_pg(-pid,sig,0)); +--- 215,232 ---- + int sys_kill(int pid,int sig) + { + struct task_struct **p = NR_TASKS + task; +! int err, retval = 0, count = 0; + + if (!pid) +! return(kill_pg(current->pgrp,sig,0)); + if (pid == -1) { + while (--p > &FIRST_TASK) +! if ((*p)->pid > 1 && *p != current) { +! ++count; +! if ((err = send_sig(sig,*p,0)) != -EPERM) +! retval = err; +! } +! return(count ? retval : -ESRCH); + } + if (pid < 0) + return(kill_pg(-pid,sig,0)); +*************** +*** 292,297 **** +--- 292,298 ---- + current->library = NULL; + current->state = TASK_ZOMBIE; + current->exit_code = code; ++ current->rss = 0; + /* + * Check to see if any process groups have become orphaned + * as a result of our exiting, and if they have any stopped +*************** +*** 413,420 **** + p->exit_code = 0; + return p->pid; + case TASK_ZOMBIE: +! current->cutime += p->utime; +! current->cstime += p->stime; + flag = p->pid; + if (stat_addr) + put_fs_long(p->exit_code, stat_addr); +--- 414,423 ---- + p->exit_code = 0; + return p->pid; + case TASK_ZOMBIE: +! current->cutime += p->utime + p->cutime; +! current->cstime += p->stime + p->cstime; +! current->cmin_flt += p->min_flt + p->cmin_flt; +! current->cmaj_flt += p->maj_flt + p->cmaj_flt; + flag = p->pid; + if (stat_addr) + put_fs_long(p->exit_code, stat_addr); +*** ../0.95a/linux/kernel/fork.c Wed Mar 4 14:11:24 1992 +--- linux/kernel/fork.c Wed Apr 1 01:27:04 1992 +*************** +*** 112,117 **** +--- 112,119 ---- + p->leader = 0; /* process leadership doesn't inherit */ + p->utime = p->stime = 0; + p->cutime = p->cstime = 0; ++ p->min_flt = p->maj_flt = 0; ++ p->cmin_flt = p->cmaj_flt = 0; + p->start_time = jiffies; + p->tss.back_link = 0; + p->tss.esp0 = PAGE_SIZE + (long) p; +*** ../0.95a/linux/kernel/sys.c Thu Feb 27 18:42:09 1992 +--- linux/kernel/sys.c Wed Apr 1 01:27:27 1992 +*************** +*** 457,467 **** +--- 457,471 ---- + r.ru_utime.tv_usec = CT_TO_USECS(current->utime); + r.ru_stime.tv_sec = CT_TO_SECS(current->stime); + r.ru_stime.tv_usec = CT_TO_USECS(current->stime); ++ r.ru_minflt = current->min_flt; ++ r.ru_majflt = current->maj_flt; + } else { + r.ru_utime.tv_sec = CT_TO_SECS(current->cutime); + r.ru_utime.tv_usec = CT_TO_USECS(current->cutime); + r.ru_stime.tv_sec = CT_TO_SECS(current->cstime); + r.ru_stime.tv_usec = CT_TO_USECS(current->cstime); ++ r.ru_minflt = current->cmin_flt; ++ r.ru_majflt = current->cmaj_flt; + } + lp = (unsigned long *) &r; + lpend = (unsigned long *) (&r+1); +*** ../0.95a/linux/kernel/chr_drv/keyboard.S Sun Mar 15 02:43:22 1992 +--- linux/kernel/chr_drv/keyboard.S Sat Apr 4 16:30:36 1992 +*************** +*** 19,25 **** + * KBD_UK for British extended keyboard + * KBD_DK for Danish keyboard + */ +- #define KBD_FINNISH + + .text + .globl _hard_reset_now +--- 19,24 ---- +*** ../0.95a/linux/kernel/chr_drv/Makefile Thu Mar 5 23:37:00 1992 +--- linux/kernel/chr_drv/Makefile Sat Apr 4 17:33:24 1992 +*************** +*** 5,22 **** + # removes any old dependencies. DON'T put your own dependencies here + # unless it's something special (ie not a .c file). + # + +- # gcc2 doesn't understand this option: +- #GCC_OPT = -fcombine-regs +- + AR =ar + AS =as + LD =ld + LDFLAGS =-s -x +! CC =gcc +! CFLAGS =-Wall -O -fstrength-reduce -fomit-frame-pointer $(GCC_OPT) \ +! -finline-functions -nostdinc -I../../include +! CPP =gcc -E -nostdinc -I../../include + + .c.s: + $(CC) $(CFLAGS) \ +--- 5,20 ---- + # removes any old dependencies. DON'T put your own dependencies here + # unless it's something special (ie not a .c file). + # ++ # Note 2! The CFLAGS definitions are now inherited from the ++ # parent makes.. ++ # + + AR =ar + AS =as + LD =ld + LDFLAGS =-s -x +! CC =gcc -nostdinc -I../../include +! CPP =cpp -nostdinc -I../../include + + .c.s: + $(CC) $(CFLAGS) \ +*************** +*** 35,41 **** + sync + + keyboard.s: keyboard.S +! $(CPP) -traditional keyboard.S -o keyboard.s + + clean: + rm -f core *.o *.a tmp_make keyboard.s +--- 33,39 ---- + sync + + keyboard.s: keyboard.S +! $(CPP) $(KEYBOARD) -traditional keyboard.S -o keyboard.s + + clean: + rm -f core *.o *.a tmp_make keyboard.s +*************** +*** 50,78 **** + ### Dependencies: + console.s console.o : console.c ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/sys/types.h ../../include/linux/mm.h \ +! ../../include/linux/kernel.h ../../include/signal.h \ +! ../../include/sys/param.h ../../include/sys/time.h ../../include/time.h \ +! ../../include/sys/resource.h ../../include/linux/timer.h \ +! ../../include/linux/tty.h ../../include/termios.h \ +! ../../include/linux/config.h ../../include/asm/io.h \ + ../../include/asm/system.h ../../include/asm/segment.h \ + ../../include/string.h ../../include/errno.h + pty.s pty.o : pty.c ../../include/linux/tty.h ../../include/termios.h \ + ../../include/sys/types.h ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/linux/mm.h ../../include/linux/kernel.h \ +! ../../include/signal.h ../../include/sys/param.h ../../include/sys/time.h \ +! ../../include/time.h ../../include/sys/resource.h \ +! ../../include/asm/system.h ../../include/asm/io.h + serial.s serial.o : serial.c ../../include/linux/tty.h ../../include/termios.h \ + ../../include/sys/types.h ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/linux/mm.h ../../include/linux/kernel.h \ +! ../../include/signal.h ../../include/sys/param.h ../../include/sys/time.h \ +! ../../include/time.h ../../include/sys/resource.h \ +! ../../include/linux/timer.h ../../include/asm/system.h \ +! ../../include/asm/io.h + tty_io.s tty_io.o : tty_io.c ../../include/ctype.h ../../include/errno.h \ + ../../include/signal.h ../../include/sys/types.h ../../include/unistd.h \ + ../../include/sys/stat.h ../../include/sys/time.h ../../include/time.h \ +--- 48,77 ---- + ### Dependencies: + console.s console.o : console.c ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/sys/types.h ../../include/sys/dirent.h ../../include/limits.h \ +! ../../include/linux/mm.h ../../include/linux/kernel.h \ +! ../../include/signal.h ../../include/sys/param.h ../../include/sys/time.h \ +! ../../include/time.h ../../include/sys/resource.h \ +! ../../include/linux/timer.h ../../include/linux/tty.h \ +! ../../include/termios.h ../../include/linux/config.h ../../include/asm/io.h \ + ../../include/asm/system.h ../../include/asm/segment.h \ + ../../include/string.h ../../include/errno.h + pty.s pty.o : pty.c ../../include/linux/tty.h ../../include/termios.h \ + ../../include/sys/types.h ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/sys/dirent.h ../../include/limits.h ../../include/linux/mm.h \ +! ../../include/linux/kernel.h ../../include/signal.h \ +! ../../include/sys/param.h ../../include/sys/time.h ../../include/time.h \ +! ../../include/sys/resource.h ../../include/asm/system.h \ +! ../../include/asm/io.h + serial.s serial.o : serial.c ../../include/linux/tty.h ../../include/termios.h \ + ../../include/sys/types.h ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/sys/dirent.h ../../include/limits.h ../../include/linux/mm.h \ +! ../../include/linux/kernel.h ../../include/signal.h \ +! ../../include/sys/param.h ../../include/sys/time.h ../../include/time.h \ +! ../../include/sys/resource.h ../../include/linux/timer.h \ +! ../../include/asm/system.h ../../include/asm/io.h + tty_io.s tty_io.o : tty_io.c ../../include/ctype.h ../../include/errno.h \ + ../../include/signal.h ../../include/sys/types.h ../../include/unistd.h \ + ../../include/sys/stat.h ../../include/sys/time.h ../../include/time.h \ +*************** +*** 80,93 **** + ../../include/sys/param.h ../../include/sys/resource.h \ + ../../include/utime.h ../../include/fcntl.h ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/linux/mm.h ../../include/linux/kernel.h \ +! ../../include/linux/tty.h ../../include/termios.h \ +! ../../include/asm/segment.h ../../include/asm/system.h + tty_ioctl.s tty_ioctl.o : tty_ioctl.c ../../include/errno.h ../../include/termios.h \ + ../../include/sys/types.h ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/linux/mm.h ../../include/linux/kernel.h \ +! ../../include/signal.h ../../include/sys/param.h ../../include/sys/time.h \ +! ../../include/time.h ../../include/sys/resource.h ../../include/linux/tty.h \ + ../../include/asm/io.h ../../include/asm/segment.h \ + ../../include/asm/system.h +--- 79,94 ---- + ../../include/sys/param.h ../../include/sys/resource.h \ + ../../include/utime.h ../../include/fcntl.h ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/sys/dirent.h ../../include/limits.h ../../include/linux/mm.h \ +! ../../include/linux/kernel.h ../../include/linux/tty.h \ +! ../../include/termios.h ../../include/asm/segment.h \ +! ../../include/asm/system.h + tty_ioctl.s tty_ioctl.o : tty_ioctl.c ../../include/errno.h ../../include/termios.h \ + ../../include/sys/types.h ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/sys/dirent.h ../../include/limits.h ../../include/linux/mm.h \ +! ../../include/linux/kernel.h ../../include/signal.h \ +! ../../include/sys/param.h ../../include/sys/time.h ../../include/time.h \ +! ../../include/sys/resource.h ../../include/linux/tty.h \ + ../../include/asm/io.h ../../include/asm/segment.h \ + ../../include/asm/system.h +*** ../0.95a/linux/kernel/chr_drv/console.c Fri Mar 13 00:37:07 1992 +--- linux/kernel/chr_drv/console.c Thu Mar 19 21:15:03 1992 +*************** +*** 456,462 **** + p++; + } + sti(); +! copy_to_cooked(tty); + } + + static void insert_char(int currcons) +--- 456,462 ---- + p++; + } + sti(); +! TTY_READ_FLUSH(tty); + } + + static void insert_char(int currcons) +*************** +*** 823,829 **** + + void do_keyboard_interrupt(void) + { +! copy_to_cooked(TTY_TABLE(0)); + timer_active &= ~(1<stopped = 1; +! TTY_WRITE(tty); + return 0; + case TCOON: + tty->stopped = 0; +! TTY_WRITE(tty); + return 0; + case TCIOFF: + if (STOP_CHAR(tty)) +--- 260,270 ---- + switch (arg) { + case TCOOFF: + tty->stopped = 1; +! TTY_WRITE_FLUSH(tty); + return 0; + case TCOON: + tty->stopped = 0; +! TTY_WRITE_FLUSH(tty); + return 0; + case TCIOFF: + if (STOP_CHAR(tty)) +*** ../0.95a/linux/kernel/chr_drv/tty_io.c Tue Mar 17 22:46:46 1992 +--- linux/kernel/chr_drv/tty_io.c Sat Apr 4 02:47:57 1992 +*************** +*** 129,141 **** + printk("copy_to_cooked: missing queues\n\r"); + return; + } +- cli(); +- if (tty->busy) { +- sti(); +- return; +- } +- tty->busy = 1; +- sti(); + while (1) { + if (EMPTY(tty->read_q)) + break; +--- 129,134 ---- +*************** +*** 167,172 **** +--- 160,166 ---- + if (c<32) + PUTCH(127,tty->write_q); + PUTCH(127,tty->write_q); ++ TTY_WRITE_FLUSH(tty); + } + DEC(tty->secondary->head); + } +*************** +*** 183,188 **** +--- 177,183 ---- + if (c<32) + PUTCH(127,tty->write_q); + PUTCH(127,tty->write_q); ++ TTY_WRITE_FLUSH(tty); + } + DEC(tty->secondary->head); + continue; +*************** +*** 197,202 **** +--- 192,198 ---- + if ((START_CHAR(tty) != _POSIX_VDISABLE) && + (c==START_CHAR(tty))) { + tty->stopped=0; ++ TTY_WRITE_FLUSH(tty); + continue; + } + } +*************** +*** 232,242 **** + PUTCH(c,tty->write_q); + } + PUTCH(c,tty->secondary); + } +! tty->write(tty); +! tty->busy = 0; + if (!EMPTY(tty->secondary)) + wake_up(&tty->secondary->proc_list); + } + + /* +--- 228,240 ---- + PUTCH(c,tty->write_q); + } + PUTCH(c,tty->secondary); ++ TTY_WRITE_FLUSH(tty); + } +! TTY_WRITE_FLUSH(tty); + if (!EMPTY(tty->secondary)) + wake_up(&tty->secondary->proc_list); ++ if (LEFT(tty->write_q) > TTY_BUF_SIZE/2) ++ wake_up(&tty->write_q->proc_list); + } + + /* +*************** +*** 305,314 **** + time = current->timeout = 0; + if (minimum>nr) + minimum = nr; +! copy_to_cooked(tty); + while (nr>0) { + if (other_tty && other_tty->write) +! TTY_WRITE(other_tty); + cli(); + if (EMPTY(tty->secondary) || (L_CANON(tty) && + !FULL(tty->read_q) && !tty->secondary->data)) { +--- 303,312 ---- + time = current->timeout = 0; + if (minimum>nr) + minimum = nr; +! TTY_READ_FLUSH(tty); + while (nr>0) { + if (other_tty && other_tty->write) +! TTY_WRITE_FLUSH(other_tty); + cli(); + if (EMPTY(tty->secondary) || (L_CANON(tty) && + !FULL(tty->read_q) && !tty->secondary->data)) { +*************** +*** 320,326 **** + break; + interruptible_sleep_on(&tty->secondary->proc_list); + sti(); +! copy_to_cooked(tty); + continue; + } + sti(); +--- 318,324 ---- + break; + interruptible_sleep_on(&tty->secondary->proc_list); + sti(); +! TTY_READ_FLUSH(tty); + continue; + } + sti(); +*************** +*** 398,404 **** + cr_flag = 0; + PUTCH(c,tty->write_q); + } +! TTY_WRITE(tty); + if (nr>0) + schedule(); + } +--- 396,402 ---- + cr_flag = 0; + PUTCH(c,tty->write_q); + } +! TTY_WRITE_FLUSH(tty); + if (nr>0) + schedule(); + } +*** ../0.95a/linux/kernel/chr_drv/serial.c Sat Mar 14 20:16:21 1992 +--- linux/kernel/chr_drv/serial.c Thu Mar 19 21:15:03 1992 +*************** +*** 26,47 **** + + static void com1_timer(void) + { +! copy_to_cooked(tty_table+64); + } + + static void com2_timer(void) + { +! copy_to_cooked(tty_table+65); + } + + static void com3_timer(void) + { +! copy_to_cooked(tty_table+66); + } + + static void com4_timer(void) + { +! copy_to_cooked(tty_table+67); + } + + static inline void do_rs_write(unsigned int port) +--- 26,47 ---- + + static void com1_timer(void) + { +! TTY_READ_FLUSH(tty_table+64); + } + + static void com2_timer(void) + { +! TTY_READ_FLUSH(tty_table+65); + } + + static void com3_timer(void) + { +! TTY_READ_FLUSH(tty_table+66); + } + + static void com4_timer(void) + { +! TTY_READ_FLUSH(tty_table+67); + } + + static inline void do_rs_write(unsigned int port) +*** ../0.95a/linux/kernel/chr_drv/pty.c Sat Jan 11 01:56:45 1992 +--- linux/kernel/chr_drv/pty.c Thu Mar 19 21:15:03 1992 +*************** +*** 25,31 **** + if (FULL(to->read_q)) { + if (FULL(to->secondary)) + break; +! copy_to_cooked(to); + continue; + } + GETCH(from->write_q,c); +--- 25,31 ---- + if (FULL(to->read_q)) { + if (FULL(to->secondary)) + break; +! TTY_READ_FLUSH(to); + continue; + } + GETCH(from->write_q,c); +*************** +*** 33,39 **** + if (current->signal & ~current->blocked) + break; + } +! copy_to_cooked(to); + wake_up(&from->write_q->proc_list); + } + +--- 33,39 ---- + if (current->signal & ~current->blocked) + break; + } +! TTY_READ_FLUSH(to); + wake_up(&from->write_q->proc_list); + } + +*** ../0.95a/linux/kernel/math/Makefile Wed Mar 4 06:14:15 1992 +--- linux/kernel/math/Makefile Sat Apr 4 17:06:02 1992 +*************** +*** 10,27 **** + AS =as + LD =ld + LDFLAGS =-s -x +! CC =gcc +! CFLAGS =-Wall -O -fstrength-reduce -fomit-frame-pointer \ +! -finline-functions -nostdinc -I../../include +! CPP =gcc -E -nostdinc -I../../include + + .c.s: +! $(CC) $(CFLAGS) \ + -S -o $*.s $< + .s.o: + $(AS) -c -o $*.o $< + .c.o: +! $(CC) $(CFLAGS) \ + -c -o $*.o $< + + OBJS = math_emulate.o error.o convert.o ea.o get_put.o \ +--- 10,25 ---- + AS =as + LD =ld + LDFLAGS =-s -x +! CC =gcc -nostdinc -I../../include +! CPP =cpp -nostdinc -I../../include + + .c.s: +! $(CC) $(CFLAGS) $(MATH_EMULATION) \ + -S -o $*.s $< + .s.o: + $(AS) -c -o $*.o $< + .c.o: +! $(CC) $(CFLAGS) $(MATH_EMULATION) \ + -c -o $*.o $< + + OBJS = math_emulate.o error.o convert.o ea.o get_put.o \ +*** ../0.95a/linux/kernel/math/math_emulate.c Thu Mar 5 22:32:44 1992 +--- linux/kernel/math/math_emulate.c Sat Apr 4 17:05:42 1992 +*************** +*** 30,37 **** + * hide most of the 387-specific things here. + */ + +- #include +- + #ifdef KERNEL_MATH_EMULATION + + #include +--- 30,35 ---- +*************** +*** 172,183 **** + real_to_real(&tmp,&ST(0)); + return; + case 0x1a: +! fcom(PST(code & 7),&tmp); +! real_to_real(&tmp,&ST(0)); + return; + case 0x1b: +! fcom(PST(code & 7),&tmp); +! real_to_real(&tmp,&ST(0)); + fpop(); + return; + case 0x1c: +--- 170,179 ---- + real_to_real(&tmp,&ST(0)); + return; + case 0x1a: +! fcom(PST(code & 7),PST(0)); + return; + case 0x1b: +! fcom(PST(code & 7),PST(0)); + fpop(); + return; + case 0x1c: +*************** +*** 201,207 **** + return; + case 0x38: + fpush(); +! ST(0) = ST((code & 7)+1); + return; + case 0x39: + fxchg(&ST(0),&ST(code & 7)); +--- 197,203 ---- + return; + case 0x38: + fpush(); +! ST(0) = ST((code+1) & 7); + return; + case 0x39: + fxchg(&ST(0),&ST(code & 7)); +*** ../0.95a/linux/kernel/blk_drv/hd.c Sun Mar 15 20:46:53 1992 +--- linux/kernel/blk_drv/hd.c Sat Apr 4 14:42:37 1992 +*************** +*** 16,21 **** +--- 16,23 ---- + * in the early extended-partition checks and added DM partitions + */ + ++ #include ++ + #include + #include + #include +*************** +*** 43,49 **** + static void bad_rw_intr(void); + + static int recalibrate = 0; +! static int reset = 1; + + /* + * This struct defines the HD's and their types. +--- 45,51 ---- + static void bad_rw_intr(void); + + static int recalibrate = 0; +! static int reset = 0; + + /* + * This struct defines the HD's and their types. +*************** +*** 77,104 **** + + static unsigned int current_minor; + + static void check_partition(unsigned int dev) + { +! int minor, i; + struct buffer_head *bh; + struct partition *p; + + if (!(bh = bread(dev,0))) { + printk("Unable to read partition table of device %04x\n",dev); + return; + } +! minor = current_minor; + if (*(unsigned short *) (bh->b_data+510) == 0xAA55) { + p = 0x1BE + (void *)bh->b_data; +! for (i=0 ; i<4 ; i++,p++) { +! if (!(hd[i+minor].nr_sects = p->nr_sects)) + continue; +! hd[i+minor].start_sect = p->start_sect; + if ((current_minor & 0x3f) >= 60) + continue; + if (p->sys_ind == EXTENDED_PARTITION) { +! current_minor += 4; +! check_partition(0x0300 | (i+minor)); + } + } + /* +--- 79,181 ---- + + static unsigned int current_minor; + ++ /* ++ * Create devices for each logical partition in an extended partition. ++ * The logical partitions form a linked list, with each entry being ++ * a partition table with two entries. The first entry ++ * is the real data partition (with a start relative to the partition ++ * table start). The second is a pointer to the next logical partition ++ * (with a start relative to the entire extended partition). ++ * We do not create a Linux partition for the partition tables, but ++ * only for the actual data partitions. ++ */ ++ static void extended_partition(unsigned int dev) ++ { ++ struct buffer_head *bh; ++ struct partition *p; ++ unsigned long first_sector, this_sector; ++ ++ first_sector = hd[MINOR(dev)].start_sect; ++ this_sector = first_sector; ++ ++ while (1) { ++ if ((current_minor & 0x3f) >= 60) ++ return; ++ if (!(bh = bread(dev,0))) { ++ printk("Unable to read partition table of device %04x\n",dev); ++ return; ++ } ++ /* ++ * This block is from a device that we're about to stomp on. ++ * So make sure nobody thinks this block is usable. ++ */ ++ bh->b_dirt=0; ++ bh->b_uptodate=0; ++ if (*(unsigned short *) (bh->b_data+510) == 0xAA55) { ++ p = 0x1BE + (void *)bh->b_data; ++ /* ++ * Process the first entry, which should be the real ++ * data partition. ++ */ ++ if (p->sys_ind == EXTENDED_PARTITION || ++ !(hd[current_minor].nr_sects = p->nr_sects)) ++ goto done; /* shouldn't happen */ ++ hd[current_minor].start_sect = this_sector + p->start_sect; ++ printk(" Logical part %d start %d size %d end %d\n\r", ++ current_minor, hd[current_minor].start_sect, ++ hd[current_minor].nr_sects, ++ hd[current_minor].start_sect + ++ hd[current_minor].nr_sects); ++ current_minor++; ++ p++; ++ /* ++ * Process the second entry, which should be a link ++ * to the next logical partition. Create a minor ++ * for this just long enough to get the next partition ++ * table. The minor will be reused for the real ++ * data partition. ++ */ ++ if (p->sys_ind != EXTENDED_PARTITION || ++ !(hd[current_minor].nr_sects = p->nr_sects)) ++ goto done; /* no more logicals in this partition */ ++ hd[current_minor].start_sect = first_sector + p->start_sect; ++ this_sector = first_sector + p->start_sect; ++ dev = 0x0300 | current_minor; ++ brelse(bh); ++ } else ++ goto done; ++ } ++ done: ++ brelse(bh); ++ } ++ + static void check_partition(unsigned int dev) + { +! int i, minor = current_minor; + struct buffer_head *bh; + struct partition *p; ++ unsigned long first_sector; + ++ first_sector = hd[MINOR(dev)].start_sect; + if (!(bh = bread(dev,0))) { + printk("Unable to read partition table of device %04x\n",dev); + return; + } +! printk("Drive %d:\n\r",minor >> 6); +! current_minor += 4; /* first "extra" minor */ + if (*(unsigned short *) (bh->b_data+510) == 0xAA55) { + p = 0x1BE + (void *)bh->b_data; +! for (i=1 ; i<=4 ; minor++,i++,p++) { +! if (!(hd[minor].nr_sects = p->nr_sects)) + continue; +! hd[minor].start_sect = first_sector + p->start_sect; +! printk(" part %d start %d size %d end %d \n\r", i, +! hd[minor].start_sect, hd[minor].nr_sects, +! hd[minor].start_sect + hd[minor].nr_sects); + if ((current_minor & 0x3f) >= 60) + continue; + if (p->sys_ind == EXTENDED_PARTITION) { +! extended_partition(0x0300 | minor); + } + } + /* +*************** +*** 106,119 **** + */ + if (*(unsigned short *) (bh->b_data+0xfc) == 0x55AA) { + p = 0x1BE + (void *)bh->b_data; +! for (i=4; i<16; i++) { + p--; + if ((current_minor & 0x3f) >= 60) + break; +! if (!(hd[current_minor+4].start_sect = p->start_sect)) + continue; +! hd[current_minor+4].nr_sects = p->nr_sects; +! current_minor++; + } + } + } else +--- 183,202 ---- + */ + if (*(unsigned short *) (bh->b_data+0xfc) == 0x55AA) { + p = 0x1BE + (void *)bh->b_data; +! for (i = 4 ; i < 16 ; i++, current_minor++) { + p--; + if ((current_minor & 0x3f) >= 60) + break; +! if (!(p->start_sect && p->nr_sects)) + continue; +! hd[current_minor].start_sect = p->start_sect; +! hd[current_minor].nr_sects = p->nr_sects; +! printk(" DM part %d start %d size %d end %d\n\r", +! current_minor, +! hd[current_minor].start_sect, +! hd[current_minor].nr_sects, +! hd[current_minor].start_sect + +! hd[current_minor].nr_sects); + } + } + } else +*************** +*** 141,156 **** + hd_info[drive].sect = *(unsigned char *) (14+BIOS); + BIOS += 16; + } +- if (hd_info[1].cyl) +- NR_HD=2; +- else +- NR_HD=1; +- #endif +- for (i=0 ; ierrors >= MAX_ERRORS) + end_request(0); + if (CURRENT->errors > MAX_ERRORS/2) +*************** +*** 361,366 **** +--- 448,457 ---- + do_hd_request(); + } + ++ /* ++ * This is another of the error-routines I don't know what to do with. The ++ * best idea seems to just set reset, and start all over again. ++ */ + static void hd_times_out(void) + { + do_hd = NULL; +*************** +*** 367,379 **** + reset = 1; + if (!CURRENT) + return; +! printk("HD timeout"); + if (++CURRENT->errors >= MAX_ERRORS) + end_request(0); + do_hd_request(); + } + +! void do_hd_request(void) + { + int i,r; + unsigned int block,dev; +--- 458,471 ---- + reset = 1; + if (!CURRENT) + return; +! printk("HD timeout\n\r"); +! cli(); + if (++CURRENT->errors >= MAX_ERRORS) + end_request(0); + do_hd_request(); + } + +! static void do_hd_request(void) + { + int i,r; + unsigned int block,dev; +*************** +*** 434,437 **** +--- 526,553 ---- + outb_p(inb_p(0x21)&0xfb,0x21); + outb(inb_p(0xA1)&0xbf,0xA1); + timer_table[HD_TIMER].fn = hd_times_out; ++ } ++ ++ int hd_ioctl(int dev, int cmd, int arg) ++ { ++ struct hd_geometry *loc = (void *) arg; ++ ++ if (!loc) ++ return -EINVAL; ++ dev = MINOR(dev) >> 6; ++ if (dev >= NR_HD) ++ return -EINVAL; ++ ++ switch (cmd) { ++ case HDIO_REQ: ++ put_fs_byte(hd_info[dev].head, ++ (char *) &loc->heads); ++ put_fs_byte(hd_info[dev].sect, ++ (char *) &loc->sectors); ++ put_fs_word(hd_info[dev].cyl, ++ (short *) &loc->cylinders); ++ return 0; ++ default: ++ return -EINVAL; ++ } + } +*** ../0.95a/linux/kernel/blk_drv/ll_rw_blk.c Fri Mar 6 03:04:44 1992 +--- linux/kernel/blk_drv/ll_rw_blk.c Sat Mar 21 12:42:01 1992 +*************** +*** 83,90 **** + req->bh->b_dirt = 0; + if (!(tmp = dev->current_request)) { + dev->current_request = req; +- sti(); + (dev->request_fn)(); + return; + } + for ( ; tmp->next ; tmp = tmp->next) { +--- 83,90 ---- + req->bh->b_dirt = 0; + if (!(tmp = dev->current_request)) { + dev->current_request = req; + (dev->request_fn)(); ++ sti(); + return; + } + for ( ; tmp->next ; tmp = tmp->next) { +*** ../0.95a/linux/kernel/blk_drv/Makefile Thu Mar 5 23:37:04 1992 +--- linux/kernel/blk_drv/Makefile Sat Apr 4 17:33:28 1992 +*************** +*** 5,19 **** + # removes any old dependencies. DON'T put your own dependencies here + # unless it's something special (ie not a .c file). + # + + AR =ar + AS =as + LD =ld + LDFLAGS =-s -x +! CC =gcc +! CFLAGS =-Wall -O -fstrength-reduce -fomit-frame-pointer \ +! -finline-functions -nostdinc -I../../include +! CPP =gcc -E -nostdinc -I../../include + + .c.s: + $(CC) $(CFLAGS) \ +--- 5,20 ---- + # removes any old dependencies. DON'T put your own dependencies here + # unless it's something special (ie not a .c file). + # ++ # Note 2! The CFLAGS definition is now inherited from the ++ # parent makefile. ++ # + + AR =ar + AS =as + LD =ld + LDFLAGS =-s -x +! CC =gcc -nostdinc -I../../include +! CPP =cpp -nostdinc -I../../include + + .c.s: + $(CC) $(CFLAGS) \ +*************** +*** 42,56 **** + + ### Dependencies: + floppy.s floppy.o : floppy.c ../../include/linux/sched.h ../../include/linux/head.h \ +! ../../include/linux/fs.h ../../include/sys/types.h ../../include/linux/mm.h \ + ../../include/linux/kernel.h ../../include/signal.h \ + ../../include/sys/param.h ../../include/sys/time.h ../../include/time.h \ + ../../include/sys/resource.h ../../include/linux/fdreg.h \ + ../../include/asm/system.h ../../include/asm/io.h \ + ../../include/asm/segment.h blk.h +! hd.s hd.o : hd.c ../../include/linux/config.h ../../include/linux/sched.h \ +! ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/sys/types.h ../../include/linux/mm.h \ + ../../include/linux/kernel.h ../../include/signal.h \ + ../../include/sys/param.h ../../include/sys/time.h ../../include/time.h \ + ../../include/sys/resource.h ../../include/linux/timer.h \ +--- 43,59 ---- + + ### Dependencies: + floppy.s floppy.o : floppy.c ../../include/linux/sched.h ../../include/linux/head.h \ +! ../../include/linux/fs.h ../../include/sys/types.h \ +! ../../include/sys/dirent.h ../../include/limits.h ../../include/linux/mm.h \ + ../../include/linux/kernel.h ../../include/signal.h \ + ../../include/sys/param.h ../../include/sys/time.h ../../include/time.h \ + ../../include/sys/resource.h ../../include/linux/fdreg.h \ + ../../include/asm/system.h ../../include/asm/io.h \ + ../../include/asm/segment.h blk.h +! hd.s hd.o : hd.c ../../include/errno.h ../../include/linux/config.h \ +! ../../include/linux/sched.h ../../include/linux/head.h \ +! ../../include/linux/fs.h ../../include/sys/types.h \ +! ../../include/sys/dirent.h ../../include/limits.h ../../include/linux/mm.h \ + ../../include/linux/kernel.h ../../include/signal.h \ + ../../include/sys/param.h ../../include/sys/time.h ../../include/time.h \ + ../../include/sys/resource.h ../../include/linux/timer.h \ +*************** +*** 58,70 **** + ../../include/asm/io.h ../../include/asm/segment.h blk.h + ll_rw_blk.s ll_rw_blk.o : ll_rw_blk.c ../../include/errno.h ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/sys/types.h ../../include/linux/mm.h \ +! ../../include/linux/kernel.h ../../include/signal.h \ +! ../../include/sys/param.h ../../include/sys/time.h ../../include/time.h \ +! ../../include/sys/resource.h ../../include/asm/system.h blk.h + ramdisk.s ramdisk.o : ramdisk.c ../../include/string.h ../../include/linux/config.h \ + ../../include/linux/sched.h ../../include/linux/head.h \ +! ../../include/linux/fs.h ../../include/sys/types.h ../../include/linux/mm.h \ + ../../include/linux/kernel.h ../../include/signal.h \ + ../../include/sys/param.h ../../include/sys/time.h ../../include/time.h \ + ../../include/sys/resource.h ../../include/linux/minix_fs.h \ +--- 61,75 ---- + ../../include/asm/io.h ../../include/asm/segment.h blk.h + ll_rw_blk.s ll_rw_blk.o : ll_rw_blk.c ../../include/errno.h ../../include/linux/sched.h \ + ../../include/linux/head.h ../../include/linux/fs.h \ +! ../../include/sys/types.h ../../include/sys/dirent.h ../../include/limits.h \ +! ../../include/linux/mm.h ../../include/linux/kernel.h \ +! ../../include/signal.h ../../include/sys/param.h ../../include/sys/time.h \ +! ../../include/time.h ../../include/sys/resource.h \ +! ../../include/asm/system.h blk.h + ramdisk.s ramdisk.o : ramdisk.c ../../include/string.h ../../include/linux/config.h \ + ../../include/linux/sched.h ../../include/linux/head.h \ +! ../../include/linux/fs.h ../../include/sys/types.h \ +! ../../include/sys/dirent.h ../../include/limits.h ../../include/linux/mm.h \ + ../../include/linux/kernel.h ../../include/signal.h \ + ../../include/sys/param.h ../../include/sys/time.h ../../include/time.h \ + ../../include/sys/resource.h ../../include/linux/minix_fs.h \ +*** ../0.95a/linux/kernel/blk_drv/blk.h Thu Mar 12 03:42:41 1992 +--- linux/kernel/blk_drv/blk.h Fri Apr 3 15:28:31 1992 +*************** +*** 78,87 **** + #define DEVICE_OFF(device) floppy_off(DEVICE_NR(device)) + + #elif (MAJOR_NR == 3) +! /* harddisk */ + #define DEVICE_NAME "harddisk" + #define DEVICE_INTR do_hd + #define DEVICE_TIMEOUT HD_TIMER + #define DEVICE_REQUEST do_hd_request + #define DEVICE_NR(device) (MINOR(device)>>6) + #define DEVICE_ON(device) +--- 78,88 ---- + #define DEVICE_OFF(device) floppy_off(DEVICE_NR(device)) + + #elif (MAJOR_NR == 3) +! /* harddisk: timeout is 6 seconds.. */ + #define DEVICE_NAME "harddisk" + #define DEVICE_INTR do_hd + #define DEVICE_TIMEOUT HD_TIMER ++ #define TIMEOUT_VALUE 600 + #define DEVICE_REQUEST do_hd_request + #define DEVICE_NR(device) (MINOR(device)>>6) + #define DEVICE_ON(device) +*************** +*** 101,110 **** + #endif + #ifdef DEVICE_TIMEOUT + +! #define SET_INTR(x) if (DEVICE_INTR = (x)) { \ +! timer_table[DEVICE_TIMEOUT].expires = jiffies + 200; \ +! timer_active |= 1< + #include +*************** +*** 22,30 **** + /* set's the trap flag. */ + #define TRAP_FLAG 0x100 + +- /* check's for granularity. */ +- #define GRANULARITY 0x00800000 +- + /* + * this is the number to subtract from the top of the stack. To find + * the local frame. +--- 23,28 ---- +*************** +*** 51,58 **** + * the offset is how far from the base addr as stored in the TSS. + * this routine assumes that all the priviledged stacks are in our + * data space. +! */ +! + static inline int get_stack_long(struct task_struct *task, int offset) + { + unsigned char *stack; +--- 49,55 ---- + * the offset is how far from the base addr as stored in the TSS. + * this routine assumes that all the priviledged stacks are in our + * data space. +! */ + static inline int get_stack_long(struct task_struct *task, int offset) + { + unsigned char *stack; +*************** +*** 69,213 **** + * data space. + */ + static inline int put_stack_long(struct task_struct *task, int offset, +! unsigned short data) + { + unsigned char * stack; + + stack = (unsigned char *) task->tss.esp0; + stack += offset; +! *(int *) stack = data; + return 0; + } + + /* +! * this routine will get a word out of an arbitrary +! * tasks data space. It likes to have the task number +! * rather than the task pointer. Perhaps the number +! * should be included in the pointer. + */ +! /* seg = 0 if I space */ +! static inline int get_long(int tsk, long addr, unsigned seg, int *data) + { +- int i; +- int limit; +- int cur; +- unsigned long address; + unsigned long page; +- unsigned oldfs; + +! /* find the task number of the current task. */ +! for (i = 0; i < NR_TASKS ; i ++) { +! if (task[i] == current) break; + } +- if (i == NR_TASKS) { +- printk("PTRACE: Can't find current task\n"); +- do_exit(SIGSEGV); +- } +- cur = i; +- +- /* we will need to check the readability of the segment +- and then the byte in order to avoid segment violations. */ +- seg++; +- limit = (task[tsk]->ldt[seg].a) & 0xffff; +- /* this should be constant amound all of our segments, but we +- had better check anyway. */ +- if (task[tsk]->ldt[seg].b & GRANULARITY) +- limit = limit << 12; +- +- if (limit <= addr+4) +- return -EIO; +- +- /* Now compute the address, and make sure that it is present. */ +- address = task[tsk]->start_code + addr; +- +- page = *((unsigned long*) ((address >> 20) & 0xffc)); +- /* see if it is present. */ + if (!(page & PAGE_PRESENT)) { +! do_no_page(0, address, task[tsk]); + } +! +! oldfs = get_fs(); +! /* now convert seg to the right format. */ +! seg = (seg << 3) | 0x4; +! +! cli(); /* we are about to change our ldt, we better do it +! with interrupts off. Perhaps we should call schedule +! first so that we won't be taking too much extra time. */ +! lldt(tsk); +! set_fs(seg); +! *data = get_fs_long((void *)addr); /* we are assuming kernel space +! is in the gdt here. */ +! lldt(cur); +! set_fs(oldfs); +! sti(); +! return 0; + } + + /* +! * this routine will get a word out of an arbitrary +! * tasks data space. It likes to have the task number +! * rather than the task pointer. Perhaps the number +! * should be included in the pointer. + */ +! /* seg = 0 if I space */ +! static inline int put_long(int tsk, long addr, int data, unsigned seg) + { +- int i; +- int limit; +- unsigned oldfs; +- unsigned long address; + unsigned long page; +- int cur; + +! /* find the task number of the current task. */ +! for (i = 0; i < NR_TASKS ; i++) { +! if (task[i] == current) break; + } +! if (i == NR_TASKS) { +! printk("PTRACE: Can't find current task\n"); +! do_exit(SIGSEGV); + } +! cur = i; + +! /* we will need to check the readability of the segment +! and then the byte in order to avoid segment violations. */ +! seg++; +! limit = (task[tsk]->ldt[seg].a) & 0xffff; +! /* this should be constant amound all of our segments, but we +! had better check anyway. */ +! if (task[tsk]->ldt[seg].b & GRANULARITY) +! limit = limit << 12; + +! if (limit <= addr+4) + return -EIO; + +! /* Now compute the address, and make sure that it is present. */ +! address = task[tsk]->start_code + addr; + +! page = *((unsigned long*) ((address >> 20) & 0xffc)); +! /* see if it is present. */ +! if (!(page & PAGE_PRESENT)) { +! do_no_page(0, address, task[tsk]); +! } +! write_verify(address); +! +! oldfs=get_fs(); +! /* now convert seg to the right format. */ +! seg = (seg << 3) | 0x4; +! +! cli(); /* we are about to change our ldt, we better do it +! with interrupts off. Perhaps we should call schedule +! first so that we won't be taking too much extra time. */ +! lldt(tsk); +! set_fs(seg); +! put_fs_long(data,(void *)addr); +! lldt(cur); +! set_fs(oldfs); +! sti(); + return 0; + } + +- + /* Perform ptrace(request, pid, addr, data) syscall */ + int sys_ptrace(unsigned long *buffer) + { +--- 66,224 ---- + * data space. + */ + static inline int put_stack_long(struct task_struct *task, int offset, +! unsigned long data) + { + unsigned char * stack; + + stack = (unsigned char *) task->tss.esp0; + stack += offset; +! *(unsigned long *) stack = data; + return 0; + } + + /* +! * This routine gets a long from any process space by following the page +! * tables. NOTE! You should check that the long isn't on a page boundary, +! * and that it is in the task area before calling this: this routine does +! * no checking. +! * +! * NOTE2! This uses "tsk->tss.cr3" even though we know it's currently always +! * zero. This routine shouldn't have to change when we make a better mm. + */ +! static unsigned long get_long(struct task_struct * tsk, +! unsigned long addr) + { + unsigned long page; + +! addr += tsk->start_code; +! repeat: +! page = tsk->tss.cr3 + ((addr >> 20) & 0xffc); +! page = *(unsigned long *) page; +! if (page & PAGE_PRESENT) { +! page &= 0xfffff000; +! page += (addr >> 10) & 0xffc; +! page = *((unsigned long *) page); + } + if (!(page & PAGE_PRESENT)) { +! do_no_page(0,addr,tsk); +! goto repeat; + } +! page &= 0xfffff000; +! page += addr & 0xfff; +! return *(unsigned long *) page; + } + + /* +! * This routine puts a long into any process space by following the page +! * tables. NOTE! You should check that the long isn't on a page boundary, +! * and that it is in the task area before calling this: this routine does +! * no checking. + */ +! static void put_long(struct task_struct * tsk, unsigned long addr, +! unsigned long data) + { + unsigned long page; + +! addr += tsk->start_code; +! repeat: +! page = tsk->tss.cr3 + ((addr >> 20) & 0xffc); +! page = *(unsigned long *) page; +! if (page & PAGE_PRESENT) { +! page &= 0xfffff000; +! page += (addr >> 10) & 0xffc; +! page = *((unsigned long *) page); + } +! if (!(page & PAGE_PRESENT)) { +! do_no_page(0,addr,tsk); +! goto repeat; + } +! if (!(page & PAGE_RW)) { +! write_verify(addr); +! goto repeat; +! } +! page &= 0xfffff000; +! page += addr & 0xfff; +! *(unsigned long *) page = data; +! } + +! /* +! * This routine checks the page boundaries, and that the offset is +! * within the task area. It then calls get_long() to read a long. +! */ +! static int read_long(struct task_struct * tsk, unsigned long addr, +! unsigned long * result) +! { +! unsigned long low,high; + +! if (addr > TASK_SIZE-4) + return -EIO; ++ if ((addr & 0xfff) > PAGE_SIZE-4) { ++ low = get_long(tsk,addr & 0xfffffffc); ++ high = get_long(tsk,(addr+4) & 0xfffffffc); ++ switch (addr & 3) { ++ case 1: ++ low >>= 8; ++ low |= high << 24; ++ break; ++ case 2: ++ low >>= 16; ++ low |= high << 16; ++ break; ++ case 3: ++ low >>= 24; ++ low |= high << 8; ++ break; ++ } ++ *result = low; ++ } else ++ *result = get_long(tsk,addr); ++ return 0; ++ } + +! /* +! * This routine checks the page boundaries, and that the offset is +! * within the task area. It then calls put_long() to write a long. +! */ +! static int write_long(struct task_struct * tsk, unsigned long addr, +! unsigned long data) +! { +! unsigned long low,high; + +! if (addr > TASK_SIZE-4) +! return -EIO; +! if ((addr & 0xfff) > PAGE_SIZE-4) { +! low = get_long(tsk,addr & 0xfffffffc); +! high = get_long(tsk,(addr+4) & 0xfffffffc); +! switch (addr & 3) { +! case 0: /* shouldn't happen, but safety first */ +! low = data; +! break; +! case 1: +! low &= 0x000000ff; +! low |= data << 8; +! high &= 0xffffff00; +! high |= data >> 24; +! break; +! case 2: +! low &= 0x0000ffff; +! low |= data << 16; +! high &= 0xffff0000; +! high |= data >> 16; +! break; +! case 3: +! low &= 0x00ffffff; +! low |= data << 24; +! high &= 0xff000000; +! high |= data >> 8; +! break; +! } +! put_long(tsk,addr & 0xfffffffc,low); +! put_long(tsk,(addr+4) & 0xfffffffc,high); +! } else +! put_long(tsk,addr,data); + return 0; + } + + /* Perform ptrace(request, pid, addr, data) syscall */ + int sys_ptrace(unsigned long *buffer) + { +*************** +*** 244,250 **** + case 2: { + int tmp,res; + +! res = get_long(childno, addr, 1, &tmp); + if (res < 0) + return res; + verify_area((void *) data, 4); +--- 255,261 ---- + case 2: { + int tmp,res; + +! res = read_long(task[childno], addr, &tmp); + if (res < 0) + return res; + verify_area((void *) data, 4); +*************** +*** 267,280 **** + /* when I and D space are seperate, this will have to be fixed. */ + case 4: /* write the word at location addr. */ + case 5: +! if (put_long(childno, addr, data, 1)) +! return -EIO; +! return 0; + + case 6: /* write the word at location addr in the USER area */ + addr = addr >> 2; /* temproary hack. */ + if (addr < 0 || addr >= 17) +! return -EIO; + if (addr == ORIG_EAX) + return -EIO; + if (addr == EFL) { /* flags. */ +--- 278,289 ---- + /* when I and D space are seperate, this will have to be fixed. */ + case 4: /* write the word at location addr. */ + case 5: +! return write_long(task[childno],addr,data); + + case 6: /* write the word at location addr in the USER area */ + addr = addr >> 2; /* temproary hack. */ + if (addr < 0 || addr >= 17) +! return -EIO; + if (addr == ORIG_EAX) + return -EIO; + if (addr == EFL) { /* flags. */ +*************** +*** 281,287 **** + data &= FLAG_MASK; + data |= get_stack_long(child, EFL*4-MAGICNUMBER) & ~FLAG_MASK; + } +- + if (put_stack_long(child, 4*addr-MAGICNUMBER, data)) + return -EIO; + return 0; +--- 290,295 ---- +*** ../0.95a/linux/lib/Makefile Thu Mar 5 20:23:23 1992 +--- linux/lib/Makefile Sat Apr 4 17:00:10 1992 +*************** +*** 6,22 **** + # unless it's something special (ie not a .c file). + # + +- # gcc2 doesn't understand some options.. +- # GCC_OPT = -fcombine-regs +- + AR =ar + AS =as + LD =ld + LDFLAGS =-s -x +! CC =gcc +! CFLAGS =-Wall -O -fstrength-reduce -fomit-frame-pointer $(GCC_OPT) \ +! -finline-functions -nostdinc -I../include +! CPP =gcc -E -nostdinc -I../include + + .c.s: + $(CC) $(CFLAGS) \ +--- 6,17 ---- + # unless it's something special (ie not a .c file). + # + + AR =ar + AS =as + LD =ld + LDFLAGS =-s -x +! CC =gcc -nostdinc -I../include +! CPP =cpp -nostdinc -I../include + + .c.s: + $(CC) $(CFLAGS) \ +*** ../0.95a/linux/mm/Makefile Tue Mar 17 11:57:15 1992 +--- linux/mm/Makefile Sat Apr 4 17:33:29 1992 +*************** +*** 1,10 **** +! CC =gcc +! CFLAGS =-O -Wall -fstrength-reduce -fomit-frame-pointer \ +! -finline-functions -nostdinc -I../include + AS =as + AR =ar + LD =ld +! CPP =gcc -E -nostdinc -I../include + + .c.o: + $(CC) $(CFLAGS) \ +--- 1,17 ---- +! # +! # Makefile for the linux memory manager. +! # +! # Note! Dependencies are done automagically by 'make dep', which also +! # removes any old dependencies. DON'T put your own dependencies here +! # unless it's something special (ie not a .c file). +! # +! # Note 2! The CFLAGS definition is now in the main makefile... +! + AS =as + AR =ar + LD =ld +! CC =gcc -nostdinc -I../include +! CPP =cpp -nostdinc -I../include + + .c.o: + $(CC) $(CFLAGS) \ +*************** +*** 32,42 **** + ### Dependencies: + memory.o : memory.c ../include/signal.h ../include/sys/types.h \ + ../include/asm/system.h ../include/linux/sched.h ../include/linux/head.h \ +! ../include/linux/fs.h ../include/linux/mm.h ../include/linux/kernel.h \ +! ../include/sys/param.h ../include/sys/time.h ../include/time.h \ +! ../include/sys/resource.h + swap.o : swap.c ../include/string.h ../include/errno.h \ + ../include/linux/mm.h ../include/linux/fs.h ../include/sys/types.h \ +! ../include/linux/kernel.h ../include/signal.h ../include/sys/stat.h \ +! ../include/linux/sched.h ../include/linux/head.h ../include/sys/param.h \ +! ../include/sys/time.h ../include/time.h ../include/sys/resource.h +--- 39,50 ---- + ### Dependencies: + memory.o : memory.c ../include/signal.h ../include/sys/types.h \ + ../include/asm/system.h ../include/linux/sched.h ../include/linux/head.h \ +! ../include/linux/fs.h ../include/sys/dirent.h ../include/limits.h \ +! ../include/linux/mm.h ../include/linux/kernel.h ../include/sys/param.h \ +! ../include/sys/time.h ../include/time.h ../include/sys/resource.h + swap.o : swap.c ../include/string.h ../include/errno.h \ + ../include/linux/mm.h ../include/linux/fs.h ../include/sys/types.h \ +! ../include/sys/dirent.h ../include/limits.h ../include/linux/kernel.h \ +! ../include/signal.h ../include/sys/stat.h ../include/linux/sched.h \ +! ../include/linux/head.h ../include/sys/param.h ../include/sys/time.h \ +! ../include/time.h ../include/sys/resource.h +*** ../0.95a/linux/mm/memory.c Tue Mar 17 22:35:13 1992 +--- linux/mm/memory.c Wed Apr 1 01:28:30 1992 +*************** +*** 165,170 **** +--- 165,171 ---- + if (!(1 & this_page)) { + if (!(new_page = get_free_page())) + return -1; ++ ++current->rss; + read_swap_page(this_page>>1, (char *) new_page); + *to_page_table = this_page; + *from_page_table = new_page | (PAGE_DIRTY | 7); +*************** +*** 316,321 **** +--- 317,323 ---- + printk("Bad things happen: page error in do_wp_page\n\r"); + do_exit(SIGSEGV); + } ++ ++current->min_flt; + un_wp_page((unsigned long *) + (((address>>10) & 0xffc) + (0xfffff000 & + *((unsigned long *) ((address>>20) &0xffc))))); +*************** +*** 429,436 **** + return 0; + } + +! void do_no_page(unsigned long error_code, +! unsigned long address, struct task_struct *tsk) + { + static unsigned int last_checked = 0; + int nr[4]; +--- 431,438 ---- + return 0; + } + +! void do_no_page(unsigned long error_code, unsigned long address, +! struct task_struct *tsk) + { + static unsigned int last_checked = 0; + int nr[4]; +*************** +*** 439,445 **** + int block,i; + struct inode * inode; + +! /* Trashing ? Make it interruptible, but don't penalize otherwise */ + for (i = 0; i < CHECK_LAST_NR; i++) + if ((address & 0xfffff000) == last_pages[i]) { + current->counter = 0; +--- 441,447 ---- + int block,i; + struct inode * inode; + +! /* Thrashing ? Make it interruptible, but don't penalize otherwise */ + for (i = 0; i < CHECK_LAST_NR; i++) + if ((address & 0xfffff000) == last_pages[i]) { + current->counter = 0; +*************** +*** 457,462 **** +--- 459,465 ---- + printk("Bad things happen: nonexistent page error in do_no_page\n\r"); + do_exit(SIGSEGV); + } ++ ++tsk->rss; + page = *(unsigned long *) ((address >> 20) & 0xffc); + /* check the page directory: make a page dir entry if no such exists */ + if (page & 1) { +*************** +*** 464,469 **** +--- 467,473 ---- + page += (address >> 10) & 0xffc; + tmp = *(unsigned long *) page; + if (tmp && !(1 & tmp)) { ++ ++tsk->maj_flt; + swap_in((unsigned long *) page); + return; + } +*************** +*** 488,499 **** + block = 0; + } + if (!inode) { + get_empty_page(address); + return; + } + if (tsk == current) +! if (share_page(inode,tmp)) +! return; + if (!(page = get_free_page())) + oom(); + /* remember that 1 block is used for header */ +--- 492,510 ---- + block = 0; + } + if (!inode) { ++ ++tsk->min_flt; ++ if (tmp > tsk->brk && tsk == current && ++ LIBRARY_OFFSET - tmp > tsk->rlim[RLIMIT_STACK].rlim_max) ++ do_exit(SIGSEGV); + get_empty_page(address); + return; + } + if (tsk == current) +! if (share_page(inode,tmp)) { +! ++tsk->min_flt; +! return; +! } +! ++tsk->maj_flt; + if (!(page = get_free_page())) + oom(); + /* remember that 1 block is used for header */ +*************** +*** 533,541 **** + void show_mem(void) + { + int i,j,k,free=0,total=0; +! int shared=0; + unsigned long * pg_tbl; + + printk("Mem-info:\n\r"); + for(i=0 ; i ++ ++ struct dirent { ++ long d_ino; ++ off_t d_off; ++ unsigned short d_reclen; ++ char d_name[NAME_MAX+1]; ++ }; ++ ++ #endif +*** ../0.95a/linux/include/unistd.h Wed Mar 4 12:56:06 1992 +--- linux/include/unistd.h Fri Apr 3 19:55:41 1992 +*************** +*** 50,55 **** +--- 50,61 ---- + #define _PC_VDISABLE 8 + #define _PC_CHOWN_RESTRICTED 9 + ++ #if 0 ++ /* XXX - illegally already. ++ * The rest of these includes are also illegal (too much pollution). ++ */ ++ #include ++ #endif + #include + #include + #include +*************** +*** 148,154 **** +--- 154,162 ---- + #define __NR_uselib 86 + #define __NR_swapon 87 + #define __NR_reboot 88 ++ #define __NR_readdir 89 + ++ /* XXX - _foo needs to be __foo, while __NR_bar could be _NR_bar. */ + #define _syscall0(type,name) \ + type name(void) \ + { \ +*************** +*** 206,224 **** + + #endif /* __LIBRARY__ */ + + extern int errno; + +! int access(const char * filename, mode_t mode); + int acct(const char * filename); +- int alarm(int sec); + int brk(void * end_data_segment); + void * sbrk(ptrdiff_t increment); + int chdir(const char * filename); +! int chmod(const char * filename, mode_t mode); +! int chown(const char * filename, uid_t owner, gid_t group); + int chroot(const char * filename); + int close(int fildes); +! int creat(const char * filename, mode_t mode); + int dup(int fildes); + int execve(const char * filename, char ** argv, char ** envp); + int execv(const char * pathname, char ** argv); +--- 214,239 ---- + + #endif /* __LIBRARY__ */ + ++ /* XXX - illegal. */ + extern int errno; + +! /* XXX - several non-POSIX functions here, and POSIX functions that are +! * supposed to be declared elsewhere. Non-promotion of short types in +! * prototypes may cause trouble. Arg names should be prefixed by +! * underscores. +! */ +! int access(const char * filename, mode_t mode); /* XXX - short type */ + int acct(const char * filename); + int brk(void * end_data_segment); ++ /* XXX - POSIX says unsigned alarm(unsigned sec) */ ++ int alarm(int sec); + void * sbrk(ptrdiff_t increment); + int chdir(const char * filename); +! int chmod(const char * filename, mode_t mode); /* XXX - short type */ +! int chown(const char * filename, uid_t owner, gid_t group); /* XXX - shorts */ + int chroot(const char * filename); + int close(int fildes); +! int creat(const char * filename, mode_t mode); /* XXX - short type */ + int dup(int fildes); + int execve(const char * filename, char ** argv, char ** envp); + int execv(const char * pathname, char ** argv); +*************** +*** 229,255 **** + volatile void exit(int status); + volatile void _exit(int status); + int fcntl(int fildes, int cmd, ...); +! int fork(void); +! int getpid(void); +! int getuid(void); +! int geteuid(void); +! int getgid(void); +! int getegid(void); + int ioctl(int fildes, int cmd, ...); + int kill(pid_t pid, int signal); + int link(const char * filename1, const char * filename2); +! int lseek(int fildes, off_t offset, int origin); +! int mknod(const char * filename, mode_t mode, dev_t dev); + int mount(const char * specialfile, const char * dir, int rwflag); + int nice(int val); + int open(const char * filename, int flag, ...); + int pause(void); + int pipe(int * fildes); + int read(int fildes, char * buf, off_t count); + int setpgrp(void); +! int setpgid(pid_t pid,pid_t pgid); +! int setuid(uid_t uid); +! int setgid(gid_t gid); + void (*signal(int sig, void (*fn)(int)))(int); + int stat(const char * filename, struct stat * stat_buf); + int fstat(int fildes, struct stat * stat_buf); +--- 244,271 ---- + volatile void exit(int status); + volatile void _exit(int status); + int fcntl(int fildes, int cmd, ...); +! pid_t fork(void); +! pid_t getpid(void); +! uid_t getuid(void); +! uid_t geteuid(void); +! gid_t getgid(void); +! gid_t getegid(void); + int ioctl(int fildes, int cmd, ...); + int kill(pid_t pid, int signal); + int link(const char * filename1, const char * filename2); +! off_t lseek(int fildes, off_t offset, int origin); +! int mknod(const char * filename, mode_t mode, dev_t dev); /* XXX - shorts */ + int mount(const char * specialfile, const char * dir, int rwflag); + int nice(int val); + int open(const char * filename, int flag, ...); + int pause(void); + int pipe(int * fildes); ++ /* XXX**2 - POSIX says unsigned count */ + int read(int fildes, char * buf, off_t count); + int setpgrp(void); +! int setpgid(pid_t pid,pid_t pgid); /* XXX - short types */ +! int setuid(uid_t uid); /* XXX - short type */ +! int setgid(gid_t gid); /* XXX - short type */ + void (*signal(int sig, void (*fn)(int)))(int); + int stat(const char * filename, struct stat * stat_buf); + int fstat(int fildes, struct stat * stat_buf); +*************** +*** 266,271 **** +--- 282,288 ---- + int utime(const char * filename, struct utimbuf * times); + pid_t waitpid(pid_t pid,int * wait_stat,int options); + pid_t wait(int * wait_stat); ++ /* XXX**2 - POSIX says unsigned count */ + int write(int fildes, const char * buf, off_t count); + int dup2(int oldfd, int newfd); + int getppid(void); +*** ../0.95a/linux/include/a.out.h Tue Sep 17 18:10:49 1991 +--- linux/include/a.out.h Sat Apr 4 00:41:52 1992 +*************** +*** 1,10 **** +! #ifndef _A_OUT_H +! #define _A_OUT_H + + #define __GNU_EXEC_MACROS__ + +! struct exec { +! unsigned long a_magic; /* Use macros N_MAGIC, etc for access */ + unsigned a_text; /* length of text, in bytes */ + unsigned a_data; /* length of data, in bytes */ + unsigned a_bss; /* length of uninitialized data area for file, in bytes */ +--- 1,13 ---- +! #ifndef __A_OUT_GNU_H__ +! #define __A_OUT_GNU_H__ + + #define __GNU_EXEC_MACROS__ + +! #ifndef __STRUCT_EXEC_OVERRIDE__ +! +! struct exec +! { +! unsigned long a_info; /* Use macros N_MAGIC, etc for access */ + unsigned a_text; /* length of text, in bytes */ + unsigned a_data; /* length of data, in bytes */ + unsigned a_bss; /* length of uninitialized data area for file, in bytes */ +*************** +*** 14,24 **** + unsigned a_drsize; /* length of relocation info for data, in bytes */ + }; + +! #ifndef N_MAGIC +! #define N_MAGIC(exec) ((exec).a_magic) + #endif + +! #ifndef OMAGIC + /* Code indicating object file or impure executable. */ + #define OMAGIC 0407 + /* Code indicating pure executable. */ +--- 17,70 ---- + unsigned a_drsize; /* length of relocation info for data, in bytes */ + }; + +! #endif /* __STRUCT_EXEC_OVERRIDE__ */ +! +! /* these go in the N_MACHTYPE field */ +! enum machine_type { +! #if defined (M_OLDSUN2) +! M__OLDSUN2 = M_OLDSUN2, +! #else +! M_OLDSUN2 = 0, + #endif ++ #if defined (M_68010) ++ M__68010 = M_68010, ++ #else ++ M_68010 = 1, ++ #endif ++ #if defined (M_68020) ++ M__68020 = M_68020, ++ #else ++ M_68020 = 2, ++ #endif ++ #if defined (M_SPARC) ++ M__SPARC = M_SPARC, ++ #else ++ M_SPARC = 3, ++ #endif ++ /* skip a bunch so we don't run into any of sun's numbers */ ++ M_386 = 100, ++ }; + +! #if !defined (N_MAGIC) +! #define N_MAGIC(exec) ((exec).a_info & 0xffff) +! #endif +! #define N_MACHTYPE(exec) ((enum machine_type)(((exec).a_info >> 16) & 0xff)) +! #define N_FLAGS(exec) (((exec).a_info >> 24) & 0xff) +! #define N_SET_INFO(exec, magic, type, flags) \ +! ((exec).a_info = ((magic) & 0xffff) \ +! | (((int)(type) & 0xff) << 16) \ +! | (((flags) & 0xff) << 24)) +! #define N_SET_MAGIC(exec, magic) \ +! ((exec).a_info = (((exec).a_info & 0xffff0000) | ((magic) & 0xffff))) +! +! #define N_SET_MACHTYPE(exec, machtype) \ +! ((exec).a_info = \ +! ((exec).a_info&0xff00ffff) | ((((int)(machtype))&0xff) << 16)) +! +! #define N_SET_FLAGS(exec, flags) \ +! ((exec).a_info = \ +! ((exec).a_info&0x00ffffff) | (((flags) & 0xff) << 24)) +! + /* Code indicating object file or impure executable. */ + #define OMAGIC 0407 + /* Code indicating pure executable. */ +*************** +*** 25,33 **** + #define NMAGIC 0410 + /* Code indicating demand-paged executable. */ + #define ZMAGIC 0413 +- #endif /* not OMAGIC */ + +! #ifndef N_BADMAG + #define N_BADMAG(x) \ + (N_MAGIC(x) != OMAGIC && N_MAGIC(x) != NMAGIC \ + && N_MAGIC(x) != ZMAGIC) +--- 71,78 ---- + #define NMAGIC 0410 + /* Code indicating demand-paged executable. */ + #define ZMAGIC 0413 + +! #if !defined (N_BADMAG) + #define N_BADMAG(x) \ + (N_MAGIC(x) != OMAGIC && N_MAGIC(x) != NMAGIC \ + && N_MAGIC(x) != ZMAGIC) +*************** +*** 37,71 **** + (N_MAGIC(x) != OMAGIC && N_MAGIC(x) != NMAGIC \ + && N_MAGIC(x) != ZMAGIC) + +! #define _N_HDROFF(x) (SEGMENT_SIZE - sizeof (struct exec)) + +! #ifndef N_TXTOFF + #define N_TXTOFF(x) \ + (N_MAGIC(x) == ZMAGIC ? _N_HDROFF((x)) + sizeof (struct exec) : sizeof (struct exec)) + #endif + +! #ifndef N_DATOFF + #define N_DATOFF(x) (N_TXTOFF(x) + (x).a_text) + #endif + +! #ifndef N_TRELOFF + #define N_TRELOFF(x) (N_DATOFF(x) + (x).a_data) + #endif + +! #ifndef N_DRELOFF + #define N_DRELOFF(x) (N_TRELOFF(x) + (x).a_trsize) + #endif + +! #ifndef N_SYMOFF + #define N_SYMOFF(x) (N_DRELOFF(x) + (x).a_drsize) + #endif + +! #ifndef N_STROFF + #define N_STROFF(x) (N_SYMOFF(x) + (x).a_syms) + #endif + + /* Address of text segment in memory after it is loaded. */ +! #ifndef N_TXTADDR + #define N_TXTADDR(x) 0 + #endif + +--- 82,116 ---- + (N_MAGIC(x) != OMAGIC && N_MAGIC(x) != NMAGIC \ + && N_MAGIC(x) != ZMAGIC) + +! #define _N_HDROFF(x) (1024 - sizeof (struct exec)) + +! #if !defined (N_TXTOFF) + #define N_TXTOFF(x) \ + (N_MAGIC(x) == ZMAGIC ? _N_HDROFF((x)) + sizeof (struct exec) : sizeof (struct exec)) + #endif + +! #if !defined (N_DATOFF) + #define N_DATOFF(x) (N_TXTOFF(x) + (x).a_text) + #endif + +! #if !defined (N_TRELOFF) + #define N_TRELOFF(x) (N_DATOFF(x) + (x).a_data) + #endif + +! #if !defined (N_DRELOFF) + #define N_DRELOFF(x) (N_TRELOFF(x) + (x).a_trsize) + #endif + +! #if !defined (N_SYMOFF) + #define N_SYMOFF(x) (N_DRELOFF(x) + (x).a_drsize) + #endif + +! #if !defined (N_STROFF) + #define N_STROFF(x) (N_SYMOFF(x) + (x).a_syms) + #endif + + /* Address of text segment in memory after it is loaded. */ +! #if !defined (N_TXTADDR) + #define N_TXTADDR(x) 0 + #endif + +*************** +*** 73,83 **** + Note that it is up to you to define SEGMENT_SIZE + on machines not listed here. */ + #if defined(vax) || defined(hp300) || defined(pyr) +! #define SEGMENT_SIZE PAGE_SIZE + #endif +- #ifdef hp300 +- #define PAGE_SIZE 4096 +- #endif + #ifdef sony + #define SEGMENT_SIZE 0x2000 + #endif /* Sony. */ +--- 118,125 ---- + Note that it is up to you to define SEGMENT_SIZE + on machines not listed here. */ + #if defined(vax) || defined(hp300) || defined(pyr) +! #define SEGMENT_SIZE page_size + #endif + #ifdef sony + #define SEGMENT_SIZE 0x2000 + #endif /* Sony. */ +*************** +*** 89,96 **** + #define SEGMENT_SIZE PAGE_SIZE + #endif + +! #define PAGE_SIZE 4096 +! #define SEGMENT_SIZE 1024 + + #define _N_SEGMENT_ROUND(x) (((x) + SEGMENT_SIZE - 1) & ~(SEGMENT_SIZE - 1)) + +--- 131,140 ---- + #define SEGMENT_SIZE PAGE_SIZE + #endif + +! #ifdef linux +! #define PAGE_SIZE 4096 +! #define SEGMENT_SIZE 1024 +! #endif + + #define _N_SEGMENT_ROUND(x) (((x) + SEGMENT_SIZE - 1) & ~(SEGMENT_SIZE - 1)) + +*************** +*** 103,113 **** + #endif + + /* Address of bss segment in memory after it is loaded. */ +! #ifndef N_BSSADDR + #define N_BSSADDR(x) (N_DATADDR(x) + (x).a_data) + #endif +! +! #ifndef N_NLIST_DECLARED + struct nlist { + union { + char *n_name; +--- 147,157 ---- + #endif + + /* Address of bss segment in memory after it is loaded. */ +! #if !defined (N_BSSADDR) + #define N_BSSADDR(x) (N_DATADDR(x) + (x).a_data) + #endif +! +! #if !defined (N_NLIST_DECLARED) + struct nlist { + union { + char *n_name; +*************** +*** 119,155 **** + short n_desc; + unsigned long n_value; + }; +! #endif + +! #ifndef N_UNDF + #define N_UNDF 0 + #endif +! #ifndef N_ABS + #define N_ABS 2 + #endif +! #ifndef N_TEXT + #define N_TEXT 4 + #endif +! #ifndef N_DATA + #define N_DATA 6 + #endif +! #ifndef N_BSS + #define N_BSS 8 + #endif +! #ifndef N_COMM +! #define N_COMM 18 +! #endif +! #ifndef N_FN + #define N_FN 15 + #endif + +! #ifndef N_EXT + #define N_EXT 1 + #endif +! #ifndef N_TYPE + #define N_TYPE 036 + #endif +! #ifndef N_STAB + #define N_STAB 0340 + #endif + +--- 163,196 ---- + short n_desc; + unsigned long n_value; + }; +! #endif /* no N_NLIST_DECLARED. */ + +! #if !defined (N_UNDF) + #define N_UNDF 0 + #endif +! #if !defined (N_ABS) + #define N_ABS 2 + #endif +! #if !defined (N_TEXT) + #define N_TEXT 4 + #endif +! #if !defined (N_DATA) + #define N_DATA 6 + #endif +! #if !defined (N_BSS) + #define N_BSS 8 + #endif +! #if !defined (N_FN) + #define N_FN 15 + #endif + +! #if !defined (N_EXT) + #define N_EXT 1 + #endif +! #if !defined (N_TYPE) + #define N_TYPE 036 + #endif +! #if !defined (N_STAB) + #define N_STAB 0340 + #endif + +*************** +*** 182,190 **** + + /* This is output from LD. */ + #define N_SETV 0x1C /* Pointer to set vector in data area. */ +! +! #ifndef N_RELOCATION_INFO_DECLARED +! + /* This structure describes a single relocation to be performed. + The text-relocation section of the file is a vector of these structures, + all of which apply to the text section. +--- 223,230 ---- + + /* This is output from LD. */ + #define N_SETV 0x1C /* Pointer to set vector in data area. */ +! +! #if !defined (N_RELOCATION_INFO_DECLARED) + /* This structure describes a single relocation to be performed. + The text-relocation section of the file is a vector of these structures, + all of which apply to the text section. +*************** +*** 212,218 **** +--- 252,264 ---- + unsigned int r_extern:1; + /* Four bits that aren't used, but when writing an object file + it is desirable to clear them. */ ++ #ifdef NS32K ++ unsigned r_bsr:1; ++ unsigned r_disp:1; ++ unsigned r_pad:2; ++ #else + unsigned int r_pad:4; ++ #endif + }; + #endif /* no N_RELOCATION_INFO_DECLARED. */ + +*** ../0.95a/linux/include/linux/hdreg.h Sat Feb 1 16:04:35 1992 +--- linux/include/linux/hdreg.h Tue Mar 31 20:50:13 1992 +*************** +*** 64,67 **** +--- 64,73 ---- + unsigned int nr_sects; /* nr of sectors in partition */ + }; + ++ #define HDIO_REQ 0x301 ++ struct hd_geometry { ++ unsigned char heads; ++ unsigned char sectors; ++ unsigned short cylinders; ++ }; + #endif +*** ../0.95a/linux/include/linux/sched.h Sat Mar 14 14:21:14 1992 +--- linux/include/linux/sched.h Wed Apr 1 01:37:45 1992 +*************** +*** 129,137 **** +--- 129,141 ---- + unsigned short gid,egid,sgid; + unsigned long timeout,alarm; + long utime,stime,cutime,cstime,start_time; ++ unsigned long min_flt, maj_flt; ++ unsigned long cmin_flt, cmaj_flt; + struct rlimit rlim[RLIM_NLIMITS]; + unsigned int flags; /* per process flags, defined below */ + unsigned short used_math; ++ unsigned short rss; /* number of resident pages */ ++ char comm[8]; + /* file system info */ + int link_count; + int tty; /* -1 if no tty, so it must be signed */ +*************** +*** 171,181 **** +--- 175,188 ---- + /* proc links*/ &init_task.task,NULL,NULL,NULL,NULL, \ + /* uid etc */ 0,0,0,0,0,0, \ + /* timeout */ 0,0,0,0,0,0,0, \ ++ /* min_flt */ 0,0,0,0, \ + /* rlimits */ { {0x7fffffff, 0x7fffffff}, {0x7fffffff, 0x7fffffff}, \ + {0x7fffffff, 0x7fffffff}, {0x7fffffff, 0x7fffffff}, \ + {0x7fffffff, 0x7fffffff}, {0x7fffffff, 0x7fffffff}}, \ + /* flags */ 0, \ + /* math */ 0, \ ++ /* rss */ 2, \ ++ /* comm */ "swapper", \ + /* fs info */ 0,-1,0022,NULL,NULL,NULL,NULL,0, \ + /* filp */ {NULL,}, \ + { \ +*** ../0.95a/linux/include/linux/sys.h Thu Feb 27 18:24:26 1992 +--- linux/include/linux/sys.h Fri Apr 3 19:56:16 1992 +*************** +*** 91,96 **** +--- 91,97 ---- + extern int sys_uselib(); + extern int sys_swapon(); + extern int sys_reboot(); ++ extern int sys_readdir(); + + fn_ptr sys_call_table[] = { sys_setup, sys_exit, sys_fork, sys_read, + sys_write, sys_open, sys_close, sys_waitpid, sys_creat, sys_link, +*************** +*** 107,113 **** + sys_setreuid,sys_setregid, sys_sigsuspend, sys_sigpending, sys_sethostname, + sys_setrlimit, sys_getrlimit, sys_getrusage, sys_gettimeofday, + sys_settimeofday, sys_getgroups, sys_setgroups, sys_select, sys_symlink, +! sys_lstat, sys_readlink, sys_uselib, sys_swapon, sys_reboot }; + + /* So we don't have to do any more manual updating.... */ + int NR_syscalls = sizeof(sys_call_table)/sizeof(fn_ptr); +--- 108,114 ---- + sys_setreuid,sys_setregid, sys_sigsuspend, sys_sigpending, sys_sethostname, + sys_setrlimit, sys_getrlimit, sys_getrusage, sys_gettimeofday, + sys_settimeofday, sys_getgroups, sys_setgroups, sys_select, sys_symlink, +! sys_lstat, sys_readlink, sys_uselib, sys_swapon, sys_reboot, sys_readdir }; + + /* So we don't have to do any more manual updating.... */ + int NR_syscalls = sizeof(sys_call_table)/sizeof(fn_ptr); +*** ../0.95a/linux/include/linux/tty.h Sun Mar 15 02:43:54 1992 +--- linux/include/linux/tty.h Thu Mar 19 21:16:26 1992 +*************** +*** 68,83 **** + struct tty_queue *secondary; + }; + +! #define TTY_WRITE(tty) \ + do { \ + cli(); \ +! if (!(tty)->busy) { \ +! (tty)->busy = 1; \ + sti(); \ + (tty)->write((tty)); \ +! (tty)->busy = 0; \ +! } else \ + sti(); \ + } while (0) + + extern struct tty_struct tty_table[]; +--- 68,105 ---- + struct tty_queue *secondary; + }; + +! /* +! * so that interrupts won't be able to mess up the +! * queues, copy_to_cooked must be atomic with repect +! * to itself, as must tty->write. +! */ +! #define TTY_WRITE_BUSY 1 +! #define TTY_READ_BUSY 2 +! +! #define TTY_WRITE_FLUSH(tty) \ + do { \ + cli(); \ +! if (!EMPTY((tty)->write_q) && !(TTY_WRITE_BUSY & (tty)->busy)) { \ +! (tty)->busy |= TTY_WRITE_BUSY; \ + sti(); \ + (tty)->write((tty)); \ +! cli(); \ +! (tty)->busy &= ~TTY_WRITE_BUSY; \ +! } \ +! sti(); \ +! } while (0) +! +! #define TTY_READ_FLUSH(tty) \ +! do { \ +! cli(); \ +! if (!EMPTY((tty)->read_q) && !(TTY_READ_BUSY & (tty)->busy)) { \ +! (tty)->busy |= TTY_READ_BUSY; \ + sti(); \ ++ copy_to_cooked((tty)); \ ++ cli(); \ ++ (tty)->busy &= ~TTY_READ_BUSY; \ ++ } \ ++ sti(); \ + } while (0) + + extern struct tty_struct tty_table[]; +*** ../0.95a/linux/include/linux/fs.h Fri Mar 13 18:55:15 1992 +--- linux/include/linux/fs.h Fri Apr 3 20:51:17 1992 +*************** +*** 7,12 **** +--- 7,13 ---- + #define _FS_H + + #include ++ #include + + /* devices are as follows: (same as minix, so we can use the minix + * file system. These are major numbers.) +*************** +*** 134,139 **** +--- 135,142 ---- + unsigned char s_lock; + unsigned char s_rd_only; + unsigned char s_dirt; ++ /* TUBE */ ++ struct super_operations *s_op; + }; + + struct file_operations { +*************** +*** 140,145 **** +--- 143,149 ---- + int (*lseek) (struct inode *, struct file *, off_t, int); + int (*read) (struct inode *, struct file *, char *, int); + int (*write) (struct inode *, struct file *, char *, int); ++ int (*readdir) (struct inode *, struct file *, struct dirent *); + }; + + struct inode_operations { +*************** +*** 156,163 **** +--- 160,184 ---- + int (*open) (struct inode *, struct file *); + void (*release) (struct inode *, struct file *); + struct inode * (*follow_link) (struct inode *, struct inode *); ++ int (*bmap) (struct inode *,int); ++ void (*truncate) (struct inode *); ++ /* added by entropy */ ++ void (*write_inode)(struct inode *inode); ++ void (*put_inode)(struct inode *inode); + }; + ++ struct super_operations { ++ void (*read_inode)(struct inode *inode); ++ void (*put_super)(struct super_block *sb); ++ }; ++ ++ struct file_system_type { ++ struct super_block *(*read_super)(struct super_block *sb,void *mode); ++ char *name; ++ }; ++ ++ extern struct file_system_type *get_fs_type(char *name); ++ + extern struct inode inode_table[NR_INODE]; + extern struct file file_table[NR_FILE]; + extern struct super_block super_block[NR_SUPER]; +*************** +*** 175,180 **** +--- 196,204 ---- + extern int bmap(struct inode * inode,int block); + extern struct inode * namei(const char * pathname); + extern struct inode * lnamei(const char * pathname); ++ extern int permission(struct inode * inode,int mask); ++ extern struct inode * _namei(const char * filename, struct inode * base, ++ int follow_links); + extern int open_namei(const char * pathname, int flag, int mode, + struct inode ** res_inode); + extern void iput(struct inode * inode); +*************** +*** 195,207 **** + extern int ROOT_DEV; + + extern void mount_root(void); + +- extern int minix_file_read(struct inode *, struct file *, char *, int); + extern int pipe_read(struct inode *, struct file *, char *, int); + extern int char_read(struct inode *, struct file *, char *, int); + extern int block_read(struct inode *, struct file *, char *, int); + +- extern int minix_file_write(struct inode *, struct file *, char *, int); + extern int pipe_write(struct inode *, struct file *, char *, int); + extern int char_write(struct inode *, struct file *, char *, int); + extern int block_write(struct inode *, struct file *, char *, int); +--- 219,231 ---- + extern int ROOT_DEV; + + extern void mount_root(void); ++ extern void lock_super(struct super_block * sb); ++ extern void free_super(struct super_block * sb); + + extern int pipe_read(struct inode *, struct file *, char *, int); + extern int char_read(struct inode *, struct file *, char *, int); + extern int block_read(struct inode *, struct file *, char *, int); + + extern int pipe_write(struct inode *, struct file *, char *, int); + extern int char_write(struct inode *, struct file *, char *, int); + extern int block_write(struct inode *, struct file *, char *, int); +*** ../0.95a/linux/include/linux/minix_fs.h Mon Mar 2 23:52:27 1992 +--- linux/include/linux/minix_fs.h Fri Apr 3 20:52:29 1992 +*************** +*** 68,76 **** +--- 68,85 ---- + extern int minix_create_block(struct inode * inode, int block); + extern int minix_bmap(struct inode * inode,int block); + ++ extern void minix_truncate(struct inode * inode); ++ extern void minix_put_super(struct super_block *sb); ++ extern struct super_block *minix_read_super(struct super_block *s,void *data); ++ extern void minix_read_inode(struct inode * inode); ++ extern void minix_write_inode(struct inode * inode); ++ + extern int minix_lseek(struct inode * inode, struct file * filp, off_t offset, int origin); + extern int minix_read(struct inode * inode, struct file * filp, char * buf, int count); + extern int minix_write(struct inode * inode, struct file * filp, char * buf, int count); ++ extern int minix_readdir(struct inode * inode, struct file * filp, struct dirent * dirent); ++ extern int minix_file_read(struct inode *, struct file *, char *, int); ++ extern int minix_file_write(struct inode *, struct file *, char *, int); + + extern struct inode_operations minix_inode_operations; + extern struct file_operations minix_file_operations; +*** ../0.95a/linux/include/asm/io.h Fri Mar 13 00:44:31 1992 +--- linux/include/asm/io.h Wed Apr 1 02:12:14 1992 +*************** +*** 1,10 **** +! static void inline outb(char value, unsigned short port) + { + __asm__ volatile ("outb %0,%1" + ::"a" ((char) value),"d" ((unsigned short) port)); + } + +! static void inline outb_p(char value, unsigned short port) + { + __asm__ volatile ("outb %0,%1\n" + "\tjmp 1f\n" +--- 1,13 ---- +! #ifndef _ASM_IO_H +! #define _ASM_IO_H +! +! extern void inline outb(char value, unsigned short port) + { + __asm__ volatile ("outb %0,%1" + ::"a" ((char) value),"d" ((unsigned short) port)); + } + +! extern void inline outb_p(char value, unsigned short port) + { + __asm__ volatile ("outb %0,%1\n" + "\tjmp 1f\n" +*************** +*** 15,21 **** + ::"a" ((char) value),"d" ((unsigned short) port)); + } + +! static unsigned char inline inb(unsigned short port) + { + unsigned char _v; + __asm__ volatile ("inb %1,%0" +--- 18,24 ---- + ::"a" ((char) value),"d" ((unsigned short) port)); + } + +! extern unsigned char inline inb(unsigned short port) + { + unsigned char _v; + __asm__ volatile ("inb %1,%0" +*************** +*** 23,29 **** + return _v; + } + +! static unsigned char inb_p(unsigned short port) + { + unsigned char _v; + __asm__ volatile ("inb %1,%0\n" +--- 26,32 ---- + return _v; + } + +! extern unsigned char inline inb_p(unsigned short port) + { + unsigned char _v; + __asm__ volatile ("inb %1,%0\n" +*************** +*** 35,37 **** +--- 38,42 ---- + :"=a" (_v):"d" ((unsigned short) port)); + return _v; + } ++ ++ #endif +*** /dev/null Sat Apr 4 17:07:54 1992 +--- linux/include/limits.h Fri Apr 3 20:08:43 1992 +*************** +*** 0 **** +--- 1,62 ---- ++ #ifndef _LIMITS_H ++ #define _LIMITS_H ++ ++ #define RAND_MAX 0x7ffffffd /* don't ask - see rand.c */ ++ ++ #define CHAR_BIT 8 ++ #define MB_LEN_MAX 1 ++ ++ #define SCHAR_MIN (-128) ++ #define SCHAR_MAX 127 ++ ++ #define UCHAR_MAX 255U ++ ++ #ifdef __CHAR_UNSIGNED__ ++ #define CHAR_MIN 0 ++ #define CHAR_MAX UCHAR_MAX ++ #else ++ #define CHAR_MIN SCHAR_MIN ++ #define CHAR_MAX SCHAR_MAX ++ #endif ++ ++ #define SHRT_MIN (-32768) ++ #define SHRT_MAX 32767 ++ ++ #define USHRT_MAX 65535U ++ ++ #define INT_MIN (-2147483648) ++ #define INT_MAX 2147483647 ++ ++ #define UINT_MAX 4294967295U ++ ++ #define LONG_MIN (-2147483648) ++ #define LONG_MAX 2147483647 ++ ++ #define ULONG_MAX 4294967295U ++ ++ /* ++ * Why are these different from the section below? -- TYT ++ */ ++ #define _POSIX_ARG_MAX 40960 /* exec() may have 40K worth of args */ ++ #define _POSIX_CHILD_MAX 6 /* a process may have 6 children */ ++ #define _POSIX_LINK_MAX 8 /* a file may have 8 links */ ++ #define _POSIX_MAX_CANON 255 /* size of the canonical input queue */ ++ #define _POSIX_MAX_INPUT 255 /* you can type 255 chars ahead */ ++ #define _POSIX_NAME_MAX 14 /* a file name may have 14 chars */ ++ #define _POSIX_NGROUPS_MAX 32 /* supplementary group IDs are optional */ ++ #define _POSIX_OPEN_MAX 16 /* a process may have 16 files open */ ++ #define _POSIX_PATH_MAX 255 /* a pathname may contain 255 chars */ ++ #define _POSIX_PIPE_BUF 512 /* pipes writes of 512 bytes must be atomic */ ++ ++ #define NGROUPS_MAX 32 /* supplemental group IDs are available */ ++ #define ARG_MAX 40960 /* # bytes of args + environ for exec() */ ++ #define CHILD_MAX 999 /* no limit :-) */ ++ #define OPEN_MAX 20 /* # open files a process may have */ ++ #define LINK_MAX 127 /* # links a file may have */ ++ #define MAX_CANON 255 /* size of the canonical input queue */ ++ #define MAX_INPUT 255 /* size of the type-ahead buffer */ ++ #define NAME_MAX 255 /* # chars in a file name */ ++ #define PATH_MAX 1024 /* # chars in a path name */ ++ #define PIPE_BUF 4095 /* # bytes in atomic write to a pipe */ ++ ++ #endif diff --git a/Linux-0.95/sources/system/linux-0.95.tar b/Linux-0.95/sources/system/linux-0.95.tar new file mode 100644 index 00000000..8b13c9a5 Binary files /dev/null and b/Linux-0.95/sources/system/linux-0.95.tar differ diff --git a/Linux-0.95/sources/system/linux-0.95.tar.Z b/Linux-0.95/sources/system/linux-0.95.tar.Z new file mode 100644 index 00000000..2da60e78 Binary files /dev/null and b/Linux-0.95/sources/system/linux-0.95.tar.Z differ diff --git a/Linux-0.95/sources/system/linux-0.95.tar.gz b/Linux-0.95/sources/system/linux-0.95.tar.gz new file mode 100644 index 00000000..5930ee03 Binary files /dev/null and b/Linux-0.95/sources/system/linux-0.95.tar.gz differ diff --git a/Linux-0.95/sources/system/linux-0.95a.tar.Z b/Linux-0.95/sources/system/linux-0.95a.tar.Z new file mode 100644 index 00000000..d1f7df5f Binary files /dev/null and b/Linux-0.95/sources/system/linux-0.95a.tar.Z differ diff --git a/Linux-0.95/sources/system/linux-0.95a.tar.gz b/Linux-0.95/sources/system/linux-0.95a.tar.gz new file mode 100644 index 00000000..f9f73c56 Binary files /dev/null and b/Linux-0.95/sources/system/linux-0.95a.tar.gz differ diff --git a/Linux-0.95/sources/system/linux-0.95c+.tar.Z b/Linux-0.95/sources/system/linux-0.95c+.tar.Z new file mode 100644 index 00000000..9c9f56e3 Binary files /dev/null and b/Linux-0.95/sources/system/linux-0.95c+.tar.Z differ diff --git a/Linux-0.95/sources/system/linux-0.95c+.tar.gz b/Linux-0.95/sources/system/linux-0.95c+.tar.gz new file mode 100644 index 00000000..1e42cc6a Binary files /dev/null and b/Linux-0.95/sources/system/linux-0.95c+.tar.gz differ diff --git a/Linux-0.95/sources/system/linux-0.95c.tar.Z b/Linux-0.95/sources/system/linux-0.95c.tar.Z new file mode 100644 index 00000000..fbcf0f5a Binary files /dev/null and b/Linux-0.95/sources/system/linux-0.95c.tar.Z differ diff --git a/Linux-0.95/sources/system/lp095a.tar.Z b/Linux-0.95/sources/system/lp095a.tar.Z new file mode 100644 index 00000000..39ea54da Binary files /dev/null and b/Linux-0.95/sources/system/lp095a.tar.Z differ diff --git a/Linux-0.95/sources/usr.bin/PBMPlus.README b/Linux-0.95/sources/usr.bin/PBMPlus.README new file mode 100644 index 00000000..011dd7f9 --- /dev/null +++ b/Linux-0.95/sources/usr.bin/PBMPlus.README @@ -0,0 +1,35 @@ + +Here are the PBMPlus utilities originally written by Jef Poskanzer, including +the libtiff libraries written by Sam Leffler of SGI. There are two files, +for those who just want binaries (sorry, no man pages there), then you should +get pbmplus.bin.tar.Z. If you want the man pages and sources get the other +file pbmplus.src.tar.Z also. + +I've built this on Linux 0.95c+, with gcc-2.1 with success. To build the +package, login as root, cd to /, and tar xzvf pbmbin.tar.Z, then tar xzvf +pmbsrc.tar.Z. Once they're done, cd to /usr/local/pbmplus10dec91/libtiff, +type make (make sure you have lots of swap space available), then cd .. +and type make install. This should build and install all the utilities and +man pages for you. All you have to do is add /usr/local/pbmplus to your +path and play with some images. + +Sorry, there's no viewer here (that I know of). Perhaps later I can add one. +But in the meantime ... Have fun. My early tests show that this runs about +1.25 times as fast as a MicroVax II, running Ultrix 3.1. + +Oh yea, I believe the binaries are built NOT using shared libs - someone pleaes +check me on this. But, the Makefiles all specifiy that NEW images built will +use shared libraries. Small inconsistency, but I figured those who would +build their own would probably want the shared binaries anyway. + +Enjoy! If you have questions I'll try to help, but I only check this mail +about once a week since it's long distance. But if you get stuck and aren't +in a hurry, email me at + + Louie.Williams@bbs.oit.unc.eud + + +Thanks to everybody responsible for Linux! I can't imagine PBMPlus on DOS! + +-Lou Williams + diff --git a/Linux-0.95/sources/usr.bin/agrep/agrep-2.04.tar.gz b/Linux-0.95/sources/usr.bin/agrep/agrep-2.04.tar.gz new file mode 100644 index 00000000..eab697fc Binary files /dev/null and b/Linux-0.95/sources/usr.bin/agrep/agrep-2.04.tar.gz differ diff --git a/Linux-0.95/sources/usr.bin/agrep/agrep.README b/Linux-0.95/sources/usr.bin/agrep/agrep.README new file mode 100644 index 00000000..b6a08204 --- /dev/null +++ b/Linux-0.95/sources/usr.bin/agrep/agrep.README @@ -0,0 +1 @@ +I believe this is about the easiest port I've never done. It compiles with GCC 1.4 (haven't gotten around to fiddling with 2.1 just yet) without a hitch.No configuration, no defines, no nuthin'. Just un-tar it, type "make", and away we go! Not so much as a peep from the compiler. I haven't tested it exhaustively, but I fooled around with it for a while, and it seems to work fine. One last note. For the time being, my only access to the internet is through a VAX running VMS. Since VMS uses 512-byte, fixed-length records forbinary files, the size will be rounded up to the next multiple of 512. Thecorrect sizes are: agrep-2.04.tar.Z - 62351 agrep.Z - 37706 agrep.ps.1.Z - 74055 agrep.ps.2.Z - 41544 I don't think it should cause any problems, but tar will probably bitch aboutthe trailing garbage. If that bothers you, use touch to fix the size beforeyou uncompress them.Ciao! Hutch. (hutchinson@wrair-emh1.army.mil)The rest of this file is the original readme from cs.arizona.edu.------------------------------------------------------------------------------This is version 2.04 of agrep - a new tool for fast text searching allowing errors.agrep is similar to egrep (or grep or fgrep), but it is much more general(and usually faster).The main changes from version 1.1 are 1) incorporating Boyer-Mooretype filtering to speed up search considerably, 2) allowing multi patterns via the -f option; this is similar to fgrep, but from our experience agrep is much faster, 3) searching for "best match" without having tospecify the number of errors allowed, and 4) ascii is no longer required.Several more options were added.To compile, simply run make in the agrep directory after untar'ingthe tar file (tar -xf agrep-2.04.tar will do it).The three most significant features of agrep that are not supported bythe grep family are 1) the ability to search for approximate patterns; for example, "agrep -2 homogenos foo" will find homogeneous as well as any other word that can be obtained from homogenos with at most 2 substitutions, insertions, or deletions. "agrep -B homogenos foo" will generate a message of the form best match has 2 errors, there are 5 matches, output them? (y/n)2) agrep is record oriented rather than just line oriented; a record is by default a line, but it can be user defined; for example, "agrep -d '^From ' 'pizza' mbox" outputs all mail messages that contain the keyword "pizza". Another example: "agrep -d '$$' pattern foo" will output all paragraphs (separated by an empty line) that contain pattern.3) multiple patterns with AND (or OR) logic queries. For example, "agrep -d '^From ' 'burger,pizza' mbox" outputs all mail messages containing at least one of the two keywords (, stands for OR). "agrep -d '^From ' 'good;pizza' mbox" outputs all mail messages containing both keywords.Putting these options together one can ask queries likeagrep -d '$$' -2 ';TheAuthor;Curriculum;<198[5-9]>' bibwhich outputs all paragraphs referencing articles in CACM between 1985 and 1989 by TheAuthor dealing with curriculum. Two errors are allowed, but they cannot be in either CACM or the year (the <> brackets forbid errors in the pattern between them). Other features include searching for regular expressions (with orwithout errors), unlimited wild cards, limiting the errors to only insertions or only substitutions or any combination, allowing each deletion, for example, to be counted as, say, 2 substitutions or 3 insertions, restricting parts of the query to be exact and parts to be approximate, and many more.agrep is available by anonymous ftp from cs.arizona.edu (IP 192.12.69.5)as agrep/agrep-2.04.tar.Z (or in uncompressed form as agrep/agrep-2.04.tar).The tar file contains the source code (in C), man pages (agrep.1),and two additional files, agrep.algorithms and agrep.chronicle,giving more information.The agrep directory also includes two postscript files: agrep.ps.1 is a technical report from June 1991 describing the design and implementation of agrep;agrep.ps.2 is a copy of the paper as appeared in the 1992Winter USENIX conference.Please mail bug reports (or any other comments) to sw@cs.arizona.edu or to udi@cs.arizona.edu.We would appreciate if users notify us (at the address above)of any extensions, improvements, or interesting uses of this software.January 17, 1992BUGS_fixed/option_update1. remove multiple definitions of some global variables.2. fix a bug in -G option.3. fix a bug in -w option.January 23, 19924. fix a bug in pipeline input.5. make the definition of word-delimiter consistant.March 16, 19926. add option '-y' which, if specified with -B option, will alwaysoutput the best-matches without a prompt.April 10, 19927. fix a bug regarding exit status.April 15, 1992 \ No newline at end of file diff --git a/Linux-0.95/sources/usr.bin/agrep/agrep.gz b/Linux-0.95/sources/usr.bin/agrep/agrep.gz new file mode 100644 index 00000000..e7946b9f Binary files /dev/null and b/Linux-0.95/sources/usr.bin/agrep/agrep.gz differ diff --git a/Linux-0.95/sources/usr.bin/agrep/agrep.ps.1.gz b/Linux-0.95/sources/usr.bin/agrep/agrep.ps.1.gz new file mode 100644 index 00000000..2abbe426 Binary files /dev/null and b/Linux-0.95/sources/usr.bin/agrep/agrep.ps.1.gz differ diff --git a/Linux-0.95/sources/usr.bin/agrep/agrep.ps.2.gz b/Linux-0.95/sources/usr.bin/agrep/agrep.ps.2.gz new file mode 100644 index 00000000..f2e30e12 Binary files /dev/null and b/Linux-0.95/sources/usr.bin/agrep/agrep.ps.2.gz differ diff --git a/Linux-0.95/sources/usr.bin/benchmark.tar.Z b/Linux-0.95/sources/usr.bin/benchmark.tar.Z new file mode 100644 index 00000000..a4fa22cc Binary files /dev/null and b/Linux-0.95/sources/usr.bin/benchmark.tar.Z differ diff --git a/Linux-0.95/sources/usr.bin/calendar.tar.Z b/Linux-0.95/sources/usr.bin/calendar.tar.Z new file mode 100644 index 00000000..1424e7f3 Binary files /dev/null and b/Linux-0.95/sources/usr.bin/calendar.tar.Z differ diff --git a/Linux-0.95/sources/usr.bin/calls.tar.gz b/Linux-0.95/sources/usr.bin/calls.tar.gz new file mode 100644 index 00000000..4cc7738a Binary files /dev/null and b/Linux-0.95/sources/usr.bin/calls.tar.gz differ diff --git a/Linux-0.95/sources/usr.bin/fileutl-3.2src.tar.Z b/Linux-0.95/sources/usr.bin/fileutl-3.2src.tar.Z new file mode 100644 index 00000000..4a1d36d6 Binary files /dev/null and b/Linux-0.95/sources/usr.bin/fileutl-3.2src.tar.Z differ diff --git a/Linux-0.95/sources/usr.bin/find-3.2-diffs b/Linux-0.95/sources/usr.bin/find-3.2-diffs new file mode 100644 index 00000000..87fbb563 --- /dev/null +++ b/Linux-0.95/sources/usr.bin/find-3.2-diffs @@ -0,0 +1,8 @@ +70c70 +< DEFS = -DDIRENT -DST_BLOCKS_MISSING -DSTDC_HEADERS -DPOSIX -DUSG +--- +> DEFS = -DDIRENT -DST_BLOCKS_MISSING -DSTDC_HEADERS -DPOSIX -DUSG -D_POSIX_SOURCE +80c80 +< bindir = $(prefix)/gnubin +--- +> bindir = $(prefix)/bin diff --git a/Linux-0.95/sources/usr.bin/floptools.shar.Z b/Linux-0.95/sources/usr.bin/floptools.shar.Z new file mode 100644 index 00000000..00d49353 Binary files /dev/null and b/Linux-0.95/sources/usr.bin/floptools.shar.Z differ diff --git a/Linux-0.95/sources/usr.bin/fm.tar.Z b/Linux-0.95/sources/usr.bin/fm.tar.Z new file mode 100644 index 00000000..683cbb08 Binary files /dev/null and b/Linux-0.95/sources/usr.bin/fm.tar.Z differ diff --git a/Linux-0.95/sources/usr.bin/iozone.tar.Z b/Linux-0.95/sources/usr.bin/iozone.tar.Z new file mode 100644 index 00000000..4ebccec6 Binary files /dev/null and b/Linux-0.95/sources/usr.bin/iozone.tar.Z differ diff --git a/Linux-0.95/sources/usr.bin/man-1.0.tar.Z b/Linux-0.95/sources/usr.bin/man-1.0.tar.Z new file mode 100644 index 00000000..abd835e1 Binary files /dev/null and b/Linux-0.95/sources/usr.bin/man-1.0.tar.Z differ diff --git a/Linux-0.95/sources/usr.bin/pbmplus.src.tar.Z b/Linux-0.95/sources/usr.bin/pbmplus.src.tar.Z new file mode 100644 index 00000000..7416f952 Binary files /dev/null and b/Linux-0.95/sources/usr.bin/pbmplus.src.tar.Z differ diff --git a/Linux-0.95/sources/usr.bin/quota-fix.diff.Z b/Linux-0.95/sources/usr.bin/quota-fix.diff.Z new file mode 100644 index 00000000..2f2a2577 Binary files /dev/null and b/Linux-0.95/sources/usr.bin/quota-fix.diff.Z differ diff --git a/Linux-0.95/sources/usr.bin/quota.tar.Z b/Linux-0.95/sources/usr.bin/quota.tar.Z new file mode 100644 index 00000000..221ae1fc Binary files /dev/null and b/Linux-0.95/sources/usr.bin/quota.tar.Z differ diff --git a/Linux-0.95/sources/usr.bin/rc-1.4b.tar.Z b/Linux-0.95/sources/usr.bin/rc-1.4b.tar.Z new file mode 100644 index 00000000..08d9a0a5 Binary files /dev/null and b/Linux-0.95/sources/usr.bin/rc-1.4b.tar.Z differ diff --git a/Linux-0.95/sources/usr.bin/rc.src.diffs.Z b/Linux-0.95/sources/usr.bin/rc.src.diffs.Z new file mode 100644 index 00000000..8168a07b Binary files /dev/null and b/Linux-0.95/sources/usr.bin/rc.src.diffs.Z differ diff --git a/Linux-0.95/sources/usr.bin/rc.src.tar.Z b/Linux-0.95/sources/usr.bin/rc.src.tar.Z new file mode 100644 index 00000000..27efca54 Binary files /dev/null and b/Linux-0.95/sources/usr.bin/rc.src.tar.Z differ diff --git a/Linux-0.95/sources/usr.bin/rcs-5.5.tar.Z b/Linux-0.95/sources/usr.bin/rcs-5.5.tar.Z new file mode 100644 index 00000000..48e90c90 Binary files /dev/null and b/Linux-0.95/sources/usr.bin/rcs-5.5.tar.Z differ diff --git a/Linux-0.95/sources/usr.bin/suite.tar.Z b/Linux-0.95/sources/usr.bin/suite.tar.Z new file mode 100644 index 00000000..b5f37cfa Binary files /dev/null and b/Linux-0.95/sources/usr.bin/suite.tar.Z differ diff --git a/Linux-0.95/sources/usr.bin/tarsplit.shar.Z b/Linux-0.95/sources/usr.bin/tarsplit.shar.Z new file mode 100644 index 00000000..353a078b Binary files /dev/null and b/Linux-0.95/sources/usr.bin/tarsplit.shar.Z differ diff --git a/Linux-0.95/sources/usr.bin/uucp-1.03-src.tar.Z b/Linux-0.95/sources/usr.bin/uucp-1.03-src.tar.Z new file mode 100644 index 00000000..9db67702 Binary files /dev/null and b/Linux-0.95/sources/usr.bin/uucp-1.03-src.tar.Z differ diff --git a/Linux-0.95/sources/usr.bin/zip10.tar.Z b/Linux-0.95/sources/usr.bin/zip10.tar.Z new file mode 100644 index 00000000..1b3bf24c Binary files /dev/null and b/Linux-0.95/sources/usr.bin/zip10.tar.Z differ diff --git a/Linux-0.95/sources/usr.games/calendar.tar.Z b/Linux-0.95/sources/usr.games/calendar.tar.Z new file mode 100644 index 00000000..1424e7f3 Binary files /dev/null and b/Linux-0.95/sources/usr.games/calendar.tar.Z differ diff --git a/Linux-0.95/sources/usr.games/dungeon.tar.Z b/Linux-0.95/sources/usr.games/dungeon.tar.Z new file mode 100644 index 00000000..a59c520e Binary files /dev/null and b/Linux-0.95/sources/usr.games/dungeon.tar.Z differ diff --git a/Linux-0.95/sources/usr.games/life.tar.Z b/Linux-0.95/sources/usr.games/life.tar.Z new file mode 100644 index 00000000..4ab4eeec Binary files /dev/null and b/Linux-0.95/sources/usr.games/life.tar.Z differ diff --git a/Linux-0.95/sources/usr.games/rain.tar.Z b/Linux-0.95/sources/usr.games/rain.tar.Z new file mode 100644 index 00000000..49da97e0 Binary files /dev/null and b/Linux-0.95/sources/usr.games/rain.tar.Z differ diff --git a/Linux-0.95/sources/usr.games/rogue.tar.Z b/Linux-0.95/sources/usr.games/rogue.tar.Z new file mode 100644 index 00000000..752af2c6 Binary files /dev/null and b/Linux-0.95/sources/usr.games/rogue.tar.Z differ diff --git a/Linux-0.95/sources/usr.games/torus.tar.Z b/Linux-0.95/sources/usr.games/torus.tar.Z new file mode 100644 index 00000000..56e57dcb Binary files /dev/null and b/Linux-0.95/sources/usr.games/torus.tar.Z differ diff --git a/Linux-0.95/sources/usr.games/worms.tar.Z b/Linux-0.95/sources/usr.games/worms.tar.Z new file mode 100644 index 00000000..3d0bf729 Binary files /dev/null and b/Linux-0.95/sources/usr.games/worms.tar.Z differ diff --git a/Linux-0.95/sources/usr.games/yahtzee.tar.Z b/Linux-0.95/sources/usr.games/yahtzee.tar.Z new file mode 100644 index 00000000..0945134a Binary files /dev/null and b/Linux-0.95/sources/usr.games/yahtzee.tar.Z differ