[comp.unix.i386] /dev/osm

pim@cti-software.nl (Pim Zandbergen) (01/05/90)

mark@zok.UUCP (Mark W. Snitily) writes:

>   Device "osm" stands for "operating system messages".  You have to have
>the driver built into the kernel.  In kconfig this is selected under
>the  "ADD FACILITY" item.  The facility you want to add is "Operating
>System Messages".  (If you already have added it, it won't show up under
>ADD FACILITY but will be listed under REMOVE FACILITY.)

I have rebuilt the kernel (ISC 2.0.1) with osm installed
but no /dev/osm is created.
Apparently there is no /etc/conf/node.d/osm file.

Can anybody help me with major and minor numbers ?

On our AT&T 3B2 running SYS V R 3.2.1 there's a utility
called 'errint' for reading /dev/osm. 
Is this supposed to be standard in SYS V R 3.2?
I can't find it in ISC 386/ix.
-- 
Pim Zandbergen                           domain : pim@cti-software.nl
CTI Software BV                          uucp   : uunet!mcsun!hp4nl!ctisbv!pim
Laan Copes van Cattenburch 70            phone  : +31 70 3542302
2585 GD The Hague, The Netherlands       fax    : +31 70 3512837

bobr@idca.tds.PHILIPS.nl (Bob Rinne) (01/08/90)

In article <1665@ctisbv.cti-software.nl> pim@cti-software.nl (Pim Zandbergen) writes:
>mark@zok.UUCP (Mark W. Snitily) writes:
>
>>   Device "osm" stands for "operating system messages".

>I have rebuilt the kernel (ISC 2.0.1) with osm installed
>but no /dev/osm is created.

>Can anybody help me with major and minor numbers ?

To get the major number you can look into field six of the mdevice entry
for osm.  Field six is the major number for character devices and field
five is the major number for block devices.  Field three will have a 'b'
for block and a 'c' for character...  more information is in mdevice(4)
in the "UNIX System V/386 Release 3.2 Programmer's Reference Manual".

The OSM minor numbers are:
	0 - read device that never returns EOF... therefore anything
	    that reads it will always be reading till a signal occurs.
	1 - reads current contents of buffer and returns EOF.
	2 - read device that never returns EOF, but starts from the
	    beginning of the circular buffer instead of the logical
	    "current" position.

I remember seeing documentation on these somewhere in the 3.0/3.1
releases from AT&T, but it is nowhere to be found in the 3.2 release
documentation.

If you don't want to do the mknod by hand everytime you reboot put
the following in the file /etc/conf/node.d/osm...

osm	osm.0	c	0
osm	osm.1	c	1
osm	osm.2	c	2

Reference idmknod(1M) in the "System/User Reference Manual".  I don't
know the prescribed names for the devices from AT&T since I can't find
any reference to them, so the names in column two are my own.

>On our AT&T 3B2 running SYS V R 3.2.1 there's a utility
>called 'errint' for reading /dev/osm. 
>Is this supposed to be standard in SYS V R 3.2?

Nope, nothing in any of the V.3.x release from AT&T so I doubt if it
would be in any 386/ix release.  "cat" will work although it works on
BUFSIZ boundaries ... This means up to BUFSIZ bytes will not be in
the log file.

-- 
#  Bob Rinne                              Internet rinne@idca.tds.philips.nl #
#  Philips TDS, Dept SSP                  UUCP       ...!mcvax!philapd!rinne #

pim@cti-software.nl (Pim Zandbergen) (01/10/90)

bobr@idca.tds.PHILIPS.nl (Bob Rinne) writes:

Bob>The OSM minor numbers are:
Bob>	0 - read device that never returns EOF... therefore anything
Bob>	    that reads it will always be reading till a signal occurs.
Bob>	1 - reads current contents of buffer and returns EOF.
Bob>	2 - read device that never returns EOF, but starts from the
Bob>	    beginning of the circular buffer instead of the logical
Bob>	    "current" position.

Bob>If you don't want to do the mknod by hand everytime you reboot put
Bob>the following in the file /etc/conf/node.d/osm...

Bob>osm	osm.0	c	0
Bob>osm	osm.1	c	1
Bob>osm	osm.2	c	2

On the 3B2 these are called /dev/osm.all /dev/osm.cur and /dev/osm,
respectively.

Me>On our AT&T 3B2 running SYS V R 3.2.1 there's a utility
Me>called 'errint' for reading /dev/osm. 
Me>Is this supposed to be standard in SYS V R 3.2?

I was mistaking, errint(1m) reads /usr/adm/errlog which is
filled with 'cat -u /dev/osm.all >/usr/adm/errlog', started
from /etc/rc.

The difference between /dev/osm in the 3B2 and System V/386
is that in the first, each line is prepended with the date,
in seconds since 1-1-1970. Errint translates this into
readable dates, so there is no use for this program in
System V/386.

Bob>Nope, nothing in any of the V.3.x release from AT&T so I doubt if it
Bob>would be in any 386/ix release.  "cat" will work although it works on
Bob>BUFSIZ boundaries ... This means up to BUFSIZ bytes will not be in
Bob>the log file.

I suppose 'cat -u' will do. Still a pity you can't find out when
the message has been printed on the console.
-- 
Pim Zandbergen                           domain : pim@cti-software.nl
CTI Software BV                          uucp   : uunet!mcsun!hp4nl!ctisbv!pim
Laan Copes van Cattenburch 70            phone  : +31 70 3542302
2585 GD The Hague, The Netherlands       fax    : +31 70 3512837

kevin@cfctech.UUCP (Kevin Darcy) (01/11/90)

In article <1668@ctisbv.cti-software.nl> pim@cti-software.nl (Pim Zandbergen) writes:
>
>>On our AT&T 3B2 running SYS V R 3.2.1 there's a utility
>>called 'errint' for reading /dev/osm. 
>>Is this supposed to be standard in SYS V R 3.2?
>
>I was mistaking, errint(1m) reads /usr/adm/errlog which is
>filled with 'cat -u /dev/osm.all >/usr/adm/errlog', started
>from /etc/rc.
>
>The difference between /dev/osm in the 3B2 and System V/386
>is that in the first, each line is prepended with the date,
>in seconds since 1-1-1970. Errint translates this into
>readable dates, so there is no use for this program in
>System V/386.
>

Actually, the errint command on our 3.2.1 3B2's is virtually useless:
it simply *strips out* the date-in-seconds from /usr/adm/errlog, thus 
leaving no chronological information. Such information is critical to us, 
as our machines constantly regurgitate old messages, thus making many 
diagnoses virtually impossible without some sort of date-decoding (the 
Hotline provided us with a "fix" for the regurgitation problem - bombing 
the sysdump partition via mkfs every time the machine is rebooted - but 
this has failed to make a difference). We ended up writing our own log 
formatter which decodes the date.

Errint also seems to be very particular about the format of the 
/usr/adm/errlog: if your message is truncated, which happens occasionally,
errint will croak at that point.
------------------------------------------------------------------------------
kevin@cfctech.UUCP		    | Kevin Darcy, Asst. Unix Systems Admin.
Soon: kevin@cfctech.cfc.com	    | CFC Technical Services 
...[mailrus!]sharkey!cfctech!kevin  | Chrysler Corporation
Voice: (313) 948-4863 Fax: ...-4975 | 27777 Franklin, Southfield, MI 48034
------------------------------------------------------------------------------

pim@cti-software.nl (Pim Zandbergen) (01/11/90)

kevin@cfctech.UUCP (Kevin Darcy) writes:

>Actually, the errint command on our 3.2.1 3B2's is virtually useless:
>it simply *strips out* the date-in-seconds from /usr/adm/errlog, thus 
>leaving no chronological information.

[...]

>We ended up writing our own log formatter which decodes the date.

errint -t would have worked too.

-- 
Pim Zandbergen                           domain : pim@cti-software.nl
CTI Software BV                          uucp   : uunet!mcsun!hp4nl!ctisbv!pim
Laan Copes van Cattenburch 70            phone  : +31 70 3542302
2585 GD The Hague, The Netherlands       fax    : +31 70 3512837