From rlhamil at smart.net  Thu Apr 26 12:04:38 2007
From: rlhamil at smart.net (Richard L. Hamilton)
Date: Thu, 26 Apr 2007 12:04:38 PDT
Subject: [approach-discuss] Re:  why the 8-character username limit?
Message-ID: <18874174.1177614308079.JavaMail.Twebapp@oss-app1>

sysconf(3c) returns values for arguments _SC_LOGNAME_MAX and _SC_LOGIN_NAME_MAX;
the former is presently just the constant LOGNAME_MAX, and the latter is LOGNAME_MAX
plus one.  It could perhaps be changed to return a configurable value that simply defaulted to the
present value, as you suggest; no new system call needed (although a change to the library
routine and maybe to an existing syscall it uses to fetch certain dynamic information).

But whether that change, plus changing L_cuserid from
#define L_cuserid 9
to
#define L_cuserid  (sysconf(_SC_LOGIN_NAME_MAX))

would be sufficient (and wouldn't break existing _source_ code), I just don't know; it may well
depend on how code uses and abuses L_cuserid.

That change by itself wouldn't AFAIK actually break any existing binaries; rather, the creation of
longer than 8 character user names would do that (and would do that now).

At least some of the library routines don't care already:

# sotruss getent passwd this_is_a_very_long_account_name
getent          ->       libc.so.1:*atexit(0xff3c0690, 0x24000, 0x0)
getent          ->       libc.so.1:*atexit(0x12d20, 0xfefea940, 0xa6bb4)
getent          ->       libc.so.1:*setlocale(0x6, 0x12e04, 0xfefea940)
getent          ->       libc.so.1:*textdomain(0x12e08, 0xfefec398, 0xfefec588)
getent          ->       libc.so.1:*strcmp(0xffbfe5d7, 0x24444, 0x7b67c)
getent          ->       libc.so.1:*strtol(0xffbfe5de, 0xffbfe384, 0xa)
getent          ->       libc.so.1:*getpwnam(0xffbfe5de, 0xffbfe384, 0xa)
getent          ->       libc.so.1:*putpwent(0x2551c, 0x245c0, 0x25540)
this_is_a_very_long_account_name:x:50000:50000:long account name test:/:
getent          ->       libc.so.1:*exit(0x0, 0xffbfe458, 0xffbfe5de)

But that's hardly conclusive; the above was in /etc/passwd; no idea if it would work with NIS, LDAP,
or the on-its-way out NIS+.

And I'd certainly want assurances that all Sun-supplied binaries, including even SFW and companion
CD stuff, would work ok with long names.

And for all I know, there might be standards issues involved.

So you can use long names now, but strictly at your own risk, which is another way of saying not
supported.  Presently, code that uses L_cuserid will continue to only be able to handle short names.
That could _maybe_ be fixed for newly compiled code, but nothing would really help old binaries
that depend on the value of L_cuserid as 9; they'd have problems with long user names no matter
what.
 
 
This message posted from opensolaris.org


From brian.gupta at gmail.com  Thu Apr 26 20:48:24 2007
From: brian.gupta at gmail.com (Brian Gupta)
Date: Thu, 26 Apr 2007 23:48:24 -0400
Subject: [approach-discuss] Re: why the 8-character username limit?
In-Reply-To: <18874174.1177614308079.JavaMail.Twebapp@oss-app1>
References: <18874174.1177614308079.JavaMail.Twebapp@oss-app1>
Message-ID: <5b5090780704262048p23dc047cg7e601c30aa1221e9@mail.gmail.com>

On 4/26/07, Richard L. Hamilton <rlhamil at smart.net> wrote:
> sysconf(3c) returns values for arguments _SC_LOGNAME_MAX and _SC_LOGIN_NAME_MAX;
> the former is presently just the constant LOGNAME_MAX, and the latter is LOGNAME_MAX
> plus one.  It could perhaps be changed to return a configurable value that simply defaulted to the
> present value, as you suggest; no new system call needed (although a change to the library
> routine and maybe to an existing syscall it uses to fetch certain dynamic information).

Richard please educate me. When a current program deals with Userid
names, does it include L_Cuserid as a "constant" variable? or does it
call sysconf and get _SC_LOGNAME/LOGINNAME_MAX?

If either is the case, I don't think you want to mess with their
behavior. What I think would be safer is an explicit new method of
getting the dynamic setting, while still supporting:
------------------------------------
sysconf(3c) returns values for arguments _SC_LOGNAME_MAX and _SC_LOGIN_NAME_MAX;
the former is presently just the constant LOGNAME_MAX, and the latter
is LOGNAME_MAX
plus one.

#define L_cuserid 9
----------------------------

For me it seems easier to predict the effects of running different
kinds of binaries. Than modifying the existing method. (It also seems
that it would be safer to support the old and new methods
simultaneously.

>
> But whether that change, plus changing L_cuserid from
> #define L_cuserid 9
> to
> #define L_cuserid  (sysconf(_SC_LOGIN_NAME_MAX))
>
> would be sufficient (and wouldn't break existing _source_ code), I just don't know; it may well
> depend on how code uses and abuses L_cuserid.
>
> That change by itself wouldn't AFAIK actually break any existing binaries; rather, the creation of
> longer than 8 character user names would do that (and would do that now).
>
> At least some of the library routines don't care already:
>
> # sotruss getent passwd this_is_a_very_long_account_name
> getent          ->       libc.so.1:*atexit(0xff3c0690, 0x24000, 0x0)
> getent          ->       libc.so.1:*atexit(0x12d20, 0xfefea940, 0xa6bb4)
> getent          ->       libc.so.1:*setlocale(0x6, 0x12e04, 0xfefea940)
> getent          ->       libc.so.1:*textdomain(0x12e08, 0xfefec398, 0xfefec588)
> getent          ->       libc.so.1:*strcmp(0xffbfe5d7, 0x24444, 0x7b67c)
> getent          ->       libc.so.1:*strtol(0xffbfe5de, 0xffbfe384, 0xa)
> getent          ->       libc.so.1:*getpwnam(0xffbfe5de, 0xffbfe384, 0xa)
> getent          ->       libc.so.1:*putpwent(0x2551c, 0x245c0, 0x25540)
> this_is_a_very_long_account_name:x:50000:50000:long account name test:/:
> getent          ->       libc.so.1:*exit(0x0, 0xffbfe458, 0xffbfe5de)
>
> But that's hardly conclusive; the above was in /etc/passwd; no idea if it would work with NIS, LDAP,
> or the on-its-way out NIS+.
>
> And I'd certainly want assurances that all Sun-supplied binaries, including even SFW and companion
> CD stuff, would work ok with long names.
>
> And for all I know, there might be standards issues involved.
>
> So you can use long names now, but strictly at your own risk, which is another way of saying not
> supported.  Presently, code that uses L_cuserid will continue to only be able to handle short names.
> That could _maybe_ be fixed for newly compiled code, but nothing would really help old binaries
> that depend on the value of L_cuserid as 9; they'd have problems with long user names no matter
> what.
>
>
> This message posted from opensolaris.org
> _______________________________________________
> approach-discuss mailing list
> approach-discuss at opensolaris.org
>


From rlhamil at smart.net  Sat Apr 28 01:37:23 2007
From: rlhamil at smart.net (Richard L. Hamilton)
Date: Sat, 28 Apr 2007 01:37:23 PDT
Subject: [approach-discuss] Re:  Re: why the 8-character username limit?
In-Reply-To: <5b5090780704262048p23dc047cg7e601c30aa1221e9@mail.gmail.com>
Message-ID: <15995550.1177749473771.JavaMail.Twebapp@oss-app1>

> Richard please educate me. When a current program
> deals with Userid
> names, does it include L_Cuserid as a "constant"
> variable? or does it
> call sysconf and get _SC_LOGNAME/LOGINNAME_MAX?

$ grep L_cuserid /usr/include/stdio.h
#define L_cuserid         9

If an already compiled program uses L_cuserid, that is simply
the constant 9, which cannot be changed.

If it is safe to change that #define (I'm not sure), it might be possible
to change it to
#define L_cuserid (sysconf(_SC_LOGIN_NAME_MAX))

in which case newly compiled programs would perceive L_cuserid as
whatever the sysconf call returned (evaluated at run time).  The problem
is that there may be contexts in which a constant can be used but a
function return value cannot; I don't know what existing source would
no longer compile if that change were made.  But it would have no effect
on existing binaries.

In any case, L_cuserid appears to have been removed from the latest update
to SUSv3, so maybe that doesn't matter so much anyway.

> If either is the case, I don't think you want to mess
> with their
> behavior. What I think would be safer is an explicit
> new method of
> getting the dynamic setting, while still supporting:
> ------------------------------------
> sysconf(3c) returns values for arguments
> _SC_LOGNAME_MAX and _SC_LOGIN_NAME_MAX;
> the former is presently just the constant
> LOGNAME_MAX, and the latter
> is LOGNAME_MAX
> plus one.
> 
> #define L_cuserid 9
> ----------------------------
> 
> For me it seems easier to predict the effects of
> running different
> kinds of binaries. Than modifying the existing
> method. (It also seems
> that it would be safer to support the old and new
> methods
> simultaneously.

Again, I think you're mixed up; the obsolete method is to use L_cuserid;
the new method is the sysconf call.  It would be a matter of having a way
to adjust what the systconf call returned, which would not affect programs
using L_cuserid.

One might be able to pull some magic by having new getpw* calls and such,
so that the old ones truncated to 8, and the new ones (aliased with
#pragma weak or the gcc equivalent, so no source changes outside the
include file would be needed) wouldn't.  That, along with the "first match
short version" rule for the former (which would cause a performance hit
sometimes) that someone mentioned, might I think make possible more or
less safe coexistance of old and new programs.

But as others have pointed out, there are plenty of other hidden assumptions
about user name length, like output columns from ls and others lining up
nicely.  Getting to the point where everything just worked with long names,
and yet nothing was broken in the process, could be difficult; depending on
what you consider to be breakage (and what commands have their output
as "committed" stability), it just might not be possible.
 
 
This message posted from opensolaris.org


From brian.gupta at gmail.com  Mon Apr 30 17:40:59 2007
From: brian.gupta at gmail.com (Brian Gupta)
Date: Mon, 30 Apr 2007 20:40:59 -0400
Subject: [approach-discuss] Re: [tools-discuss] Pkg proposal: top
In-Reply-To: <20070501002845.GB654502@sun.com>
References: <5b5090780704301705v4e5ef5cvd56ac0fe395328b1@mail.gmail.com>
	<20070501001643.GB641694@sun.com>
	<5b5090780704301719o51810845je2cf73ea00c23786@mail.gmail.com>
	<20070501002845.GB654502@sun.com>
Message-ID: <5b5090780704301740s4001029asa72d28dda0e9edc4@mail.gmail.com>

(I hope I have moved this thread to the appropriate groups:
"gnu-sol-discuss" "approach-discuss"). (I am just ccing tools-discuss, to
let people know where I am moving the discussion)

Almost all other FOSS operating systems use top to display a dynamic list of
processes. Solaris includes prstat, which A) is an unfamiliar name to non
Solaris folk, and B) doesn't support all the in application commands.

-Brian

P.S. - My apologies for posting to the wrong board.

On 4/30/07, Keith M Wesolowski <keith.wesolowski at sun.com> wrote:
>
> On Mon, Apr 30, 2007 at 08:19:12PM -0400, Brian Gupta wrote:
>
> > How do you propose to make top more accessable to non Solaris users?
> (prstat
> > is Solaris only)
>
> Actually, prstat is part of OpenSolaris, so it's not "Solaris only"
> though I suppose you really mean it's "OpenSolaris-only."  It might be
> interesting to consider a small compatibility wrapper that translates
> top options to prstat options, or perhaps a top-compatibility mode in
> prstat itself.  The Approachability Community Group might have more
> ideas - that's why the new project instantiation process directs
> project teams to the Community Groups.
>
> Just adding top to OpenSolaris is most definitely the wrong answer
> here; it has the exact same function as prstat, but consumes 2-3x the
> resources to perform it.  There's nothing wrong with having something
> that's OpenSolaris-only; this community's objective is not to clone
> someone's favourite GNU/Linux distribution with the OpenSolaris kernel
> underneath, but to create the world's best operating system.
> Sometimes compatibility with other systems is easy, and we should do
> it; sometimes it's not worth it.  You need to go figure out which
> bucket this belongs in.
>
> --
> Keith M Wesolowski              "Sir, we're surrounded!"
> FishWorks                       "Excellent; we can attack in any
> direction!"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.opensolaris.org/pipermail/approach-discuss/attachments/20070430/6313fa05/attachment.html>

From Richard.Elling at Sun.COM  Mon Apr 30 18:23:32 2007
From: Richard.Elling at Sun.COM (Richard Elling)
Date: Mon, 30 Apr 2007 18:23:32 -0700
Subject: [approach-discuss] Re: [tools-discuss] Pkg proposal: top
In-Reply-To: <5b5090780704301740s4001029asa72d28dda0e9edc4@mail.gmail.com>
References: <5b5090780704301705v4e5ef5cvd56ac0fe395328b1@mail.gmail.com>
	<20070501001643.GB641694@sun.com>
	<5b5090780704301719o51810845je2cf73ea00c23786@mail.gmail.com>
	<20070501002845.GB654502@sun.com>
	<5b5090780704301740s4001029asa72d28dda0e9edc4@mail.gmail.com>
Message-ID: <46369694.5080409@sun.com>

Solaris ships with top, but it is cleverly hidden on the Companion CD,
and has been for uhmm... maybe 10 years or so.  Perhaps the only issue
here is the bundling and PATH?

There are many of us who get used to the features of prstat that don't
exist in top, and therefore forget top exists.  Going forward, the system
monitor may win over both, presuming we can put into it the features we need.
  -- richard

Brian Gupta wrote:
> (I hope I have moved this thread to the appropriate groups: 
> "gnu-sol-discuss" "approach-discuss"). (I am just ccing tools-discuss, 
> to let people know where I am moving the discussion)
> 
> Almost all other FOSS operating systems use top to display a dynamic 
> list of processes. Solaris includes prstat, which A) is an unfamiliar 
> name to non Solaris folk, and B) doesn't support all the in application 
> commands.
> 
> -Brian
> 
> P.S. - My apologies for posting to the wrong board.
> 
> On 4/30/07, *Keith M Wesolowski* < keith.wesolowski at sun.com 
> <mailto:keith.wesolowski at sun.com>> wrote:
> 
>     On Mon, Apr 30, 2007 at 08:19:12PM -0400, Brian Gupta wrote:
> 
>      > How do you propose to make top more accessable to non Solaris
>     users? (prstat
>      > is Solaris only)
> 
>     Actually, prstat is part of OpenSolaris, so it's not "Solaris only"
>     though I suppose you really mean it's "OpenSolaris-only."  It might be
>     interesting to consider a small compatibility wrapper that translates
>     top options to prstat options, or perhaps a top-compatibility mode in
>     prstat itself.  The Approachability Community Group might have more
>     ideas - that's why the new project instantiation process directs
>     project teams to the Community Groups.
> 
>     Just adding top to OpenSolaris is most definitely the wrong answer
>     here; it has the exact same function as prstat, but consumes 2-3x the
>     resources to perform it.  There's nothing wrong with having something
>     that's OpenSolaris-only; this community's objective is not to clone
>     someone's favourite GNU/Linux distribution with the OpenSolaris kernel
>     underneath, but to create the world's best operating system.
>     Sometimes compatibility with other systems is easy, and we should do
>     it; sometimes it's not worth it.  You need to go figure out which
>     bucket this belongs in.
> 
>     --
>     Keith M Wesolowski              "Sir, we're surrounded!"
>     FishWorks                       "Excellent; we can attack in any
>     direction!"
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> approach-discuss mailing list
> approach-discuss at opensolaris.org


From brian.gupta at gmail.com  Mon Apr 30 19:29:23 2007
From: brian.gupta at gmail.com (Brian Gupta)
Date: Mon, 30 Apr 2007 22:29:23 -0400
Subject: [approach-discuss] Re: [tools-discuss] Pkg proposal: top
In-Reply-To: <46369694.5080409@sun.com>
References: <5b5090780704301705v4e5ef5cvd56ac0fe395328b1@mail.gmail.com>
	<20070501001643.GB641694@sun.com>
	<5b5090780704301719o51810845je2cf73ea00c23786@mail.gmail.com>
	<20070501002845.GB654502@sun.com>
	<5b5090780704301740s4001029asa72d28dda0e9edc4@mail.gmail.com>
	<46369694.5080409@sun.com>
Message-ID: <5b5090780704301929n379abfd0l28e02449390f2836@mail.gmail.com>

>
> Solaris ships with top, but it is cleverly hidden on the Companion CD,
> and has been for uhmm... maybe 10 years or so.  Perhaps the only issue
> here is the bundling and PATH?


Does it have to remain hidden? /usr/bin/top would probably be an easier
place to find it. A solution might be as simple as top being linked to a
script that explains to users prstat useage.

There are many of us who get used to the features of prstat that don't
> exist in top, and therefore forget top exists.  Going forward, the system
> monitor may win over both, presuming we can put into it the features we
> need.
>   -- richard
>

What is "The system monitor"? (Could you please provide a link?) Could
"system monitor" support prstat and top "perrsonalities"?

- Thanks.
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.opensolaris.org/pipermail/approach-discuss/attachments/20070430/c375fd0f/attachment.html>