From: wutcd@chemnitz.guug.de (Joerg Wunsch)
Subject: Re: [386BSD] fixing ps: major/minor numbers for /dev/console wrong?
Organization: tu-chemnitz
Date: Sun, 27 Sep 1992 22:29:01 GMT

ghod@drycas.club.cc.cmu.edu writes:

>Greetings...
greetings return:-)

> [some ps trouble...]

> [1) some names not found...]
>Problem #1 is not, ps's fault: it's the kernel. The stock kernel in the 0.1
>...
Okay, it's quiet clear: the dist kernel had to fit onto a diskette:-)

>2) it returns '??' instead of 'co' as the controlling terminal for
>   processes started from the console.

>Problem #2 is what I really want to discuss. After obtaining the source code
>to ps and twiddling with devname.c so that it would print out device numbers,
>I discovered that it thinks the console device is at major number 12, minor
>number 0. However, the console entry in the /dev directory says it's at
>major number 0, minor number 0 (and a character special device). This is
>WRONG WRONG WRONG!!! /dev/wd0a is *ALSO* at major 0, minor 0 (a block special
>device). Now I don't care that one is a character special file and the
>other is a block special file, YOU CAN'T HAVE TWO DIFFERENT DEVICES WITH THE
>SAME MAJOR/MINOR NUMBERS!!! If it happens that someone has already posted
>an article about this, I apologize for wasting bandwitdh, but there's nothing
>about this in the FAQ file (that I could see). I have since created a new
>/dev/console at major 12, minor 0: everything still works and ps can now
>identify the console device correctly. If someone knows of some
>other driver that might also wind up using this major/minor combination,
>please let me know by posting or e-mail.
Thanks for the hints. I found this appearance to be not fine, too. But,
i don't guess there aren't allowed two different devices with same major/
minor #'s at all: every source says that block and character devices are
very distinct in all way. So they can share the major numbers.
Must take the problem at the other end... Btw., a clear strategy for
assigning major numbers is still missing. Probably there should be a
reserved area assinged only by the ``prime developers'' within official
releases, and a ``private space'' for user's extensions. The problems
continues, MAKEDEV will create entries for /dev/std{in,out,err} and
/dev/fd/* containing (c) major # 53 -- but the cdevsw table is consi-
derably smaller yet! But at least, some drivers for line printers,
add-on multiport cards and so on should be taken into consideration.


>4) it never prints the arguments used to invoke processes (i.e. it'll
>   show you (ps), which is the command name, but not 'ps -aux' which
>   is the command line invokation).

Urrgh, i guess it's a general BSD problem (or really only on 386BSD -
i'm unsure). The user structure (or proc? - some days have been gone since
i had a look on this) is not intended to store such information, so
only the command name is remembered (other than on SysV). Note that
a SysV is able to remember only a small amount of command args, too. Actually,
this may be as little as 64 chars or so. But, to the origin of the
question, if you want to have the command args to be displayed by any
command, you'll have to alter three things:

	i)	some sys header files to make space for this info
	ii)	kern_execve.c to store this information when exec'ing
		a new program
	iii)	(the easiest task) ps or any other prog to make it
		display this info

Perhaps not as few to be done by a single site without consulting
``the whole world'' to discuss this before:-(

Not the best news, but i hope clear enough.
	- 73, J"org

--
J"org Wunsch, TCD GmbH Dresden, R"ahnitzgasse 18, D-O-8060 Dresden
                                                              \     ~.~. 
	joerg_wunsch%bonnie@hadrian.hrz.tu-chemnitz.de         \   ~  | ~ 
	voice: +49-351-5965 137                                 \    ===