Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) wrote:
> Be careful, David Korn ans I do not have own printf() iplementations to grant
> 100% portability. There may be problems if you let a UCB program use the POSIX
> implementation.
>
Sorry for the typo: "David Korn and I do have own p
"Garrett D'Amore" wrote:
> Differences in libucb implementation
>
>
> nlist()- UCB has local implementation supporting COFF (a.out). This
> one we would have to continue to provide for legacy apps.
Note: COFF is not a.out.
> readdir()
>readdir()- Different implementations, but apparently identical
> semantics and structures. Could probably be eliminated.
Nope, /usr/ucbinclude/sys/dir.h vs
>re_comp()
>re_exec()- These are backed by nearly identical sources, with just
> some stylistic and lint fixes
>Gary Winiger wrote:
>>> This project proposes changing the maximum value for NGROUPS_MAX
>>> from 32 to 1024 by changing the definition of NGROUPS_UMAX from 32
>>> to 1024.
>>
>>> NGROUPS_MAX as defined by different Unix versions are as follows
>>> (http://www.j3e.de/ngroups.html):
>>>
>>> L
>> This project proposes changing the maximum value for NGROUPS_MAX
>> from 32 to 1024 by changing the definition of NGROUPS_UMAX from 32
>> to 1024.
>
>> NGROUPS_MAX as defined by different Unix versions are as follows
>> (http://www.j3e.de/ngroups.html):
>>
>> Linux Kernel >= 2.6.3
>> Ucred routines will shrink the actual size of the ucred exchanges: the
>> ucred structures will "shrink to fit" and only processes which use a lot
>> of groups will pay for this in ucred exchanges.
>
>How does this work? The size of a ucred is not passed around, but
>required to be ucred_size(
Garrett D'Amore wrote:
> Btw, I just finished an analysis of what is in libucb. (I've not check
> the other libraries, most especially termcap, yet.) My findings show
> that there is a lot there that could simply trivially be eliminated.
> Here's the detailed analysis:
>
> First I started by
Darren J Moffat wrote:
>
> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
> This information is Copyright 2009 Sun Microsystems
> 1. Introduction
> 1.1. Project/Component Working Name:
>libpcsclite EOF and Removal
> 1.2. Name of Document Author/Supplier:
>Author: Da
>It's quite possible that this is all just a vain effort to tilt at
>windmills, but I at least wanted to have the *discussion*. This seemed
>like a rare opportunity to have such a discussion. If we deliver
>Solaris.next with these components, then its likely that another
>opportunity to dis
"Garrett D'Amore" wrote:
> Okay, corrected I stand. Although I *suspect* this problem could be
> corrected too. The library is coming in via the libc, not via the
> application pulling it in directly. (So if the relevant 4lib libraries
> were compiled to use normal libc, or got the importan
On Thu, Oct 8, 2009 at 3:40 PM, Garrett D'Amore wrote:
> Okay, corrected I stand. ?Although I *suspect* this problem could be
> corrected too. ?The library is coming in via the libc, not via the
> application pulling it in directly. ?(So if the relevant 4lib libraries were
> compiled to use normal
>Actually, looking at the code, I don't see how /usr/ucblib is used by
>4.x *binaries*. I.e. if you have a SunOS 4.x binary, it looks like you
>get the libraries in /usr/4lib, using the a.out exec module. I don't
>think you wind up using any of the ELF stuff in /usr/ucblib.
dump -Lv /usr/4li
I've heard this affects NFS when using AUTH_SYS (still common).
What impact will be seen there?
Here's a blog with a good description of the NFS problem:
http://nfsworld.blogspot.com/2005/03/whats-deal-on-16-group-id-limitation.html
> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
> This i
On Thu, Oct 8, 2009 at 3:14 PM, Garrett D'Amore wrote:
> Actually, looking at the code, I don't see how /usr/ucblib is used by 4.x
> *binaries*. ?I.e. if you have a SunOS 4.x binary, it looks like you get the
> libraries in /usr/4lib, using the a.out exec module. ?I don't think you wind
> up using
There is a large body of code, and a bunch of vectoring through
tables, within ld.so.1 that support the loading/relocation and
symbol lookup of 4.x applications.
There's AOUT processing in exec() and mmapobj() too.
And we've had oodles of fun massaging the Unified Process Model
into being able to
http://www.opensolaris.org/os/community/arc/announcements/
OpenSolaris ARC Agenda
TELECONFERENCE NUMBERS:
(866)545-5223 (Within US)
(215) 446-3661 (International)
ACCESS CODE 939-55-86
Times are US/Pacific Timezone
ARC meetings are recorded.
10/13/2009
No meeting
10/14/2009
"Garrett D'Amore - sun microsystems" wrote:
> COMMANDS IN /usr/ucb/
> -
>
> One possible concern is our own commands that are delivered in /usr/ucb.
>
> The project team has undertaken the effort to investigate these further.
> All of them have now been converted (in a local
Joerg,
> Note that you of course cannot remove /etc/termcap and that you should think
> about upgrading the file from time to time.
>
My first recollection of /etc/termcap was on an Altos 986 running Xenix
3.0b in the early 80's. I must get my one out of the cupboard downstairs
and crank it
> >> This project proposes changing the maximum value for NGROUPS_MAX
> >> from 32 to 1024 by changing the definition of NGROUPS_UMAX from 32
> >> to 1024.
> >
> >> NGROUPS_MAX as defined by different Unix versions are as follows
> >> (http://www.j3e.de/ngroups.html):
> >>
> >>Linux Kernel >=
Btw, I just finished an analysis of what is in libucb. (I've not check
the other libraries, most especially termcap, yet.) My findings show
that there is a lot there that could simply trivially be eliminated.
Here's the detailed analysis:
First I started by comparing differences between libc
On Thu, Oct 08, 2009 at 02:23:11AM -0700, Casper Dik wrote:
> The use for a larger number of groups is described in CR 4088757,
> particular in the case of Samba servers and ADS clients; the
> Samba servers map every SID to a Unix group. Users with more
> than 32 groups SIDs are common. We've see
>The title seems slightly misnamed. This isn't just libucb; isn't it really
>the removal of SunOS 4 binary compatibility?
>
Correct; the SUNWbcp package (SunOS 4.x Binary Compatibity) uses these
libraries.
Are these libraries listed in the SPARC ABI?
Just removing the compile symlinks I have no
Gary Winiger wrote:
>> This project proposes changing the maximum value for NGROUPS_MAX
>> from 32 to 1024 by changing the definition of NGROUPS_UMAX from 32
>> to 1024.
>
>> NGROUPS_MAX as defined by different Unix versions are as follows
>> (http://www.j3e.de/ngroups.html):
>>
>> Linux Kern
Garrett D'Amore - sun microsystems wrote:
> The following fast track (submitted on my own behalf) straddles (IMO) the
> boundary between a full-case and a fast track, primarily because of the
> impact it has on what are presumed to be Committed interfaces.
Thanks for doing this; it's well past tim
> This project proposes changing the maximum value for NGROUPS_MAX
> from 32 to 1024 by changing the definition of NGROUPS_UMAX from 32
> to 1024.
> NGROUPS_MAX as defined by different Unix versions are as follows
> (http://www.j3e.de/ngroups.html):
>
> Linux Kernel >= 2.6.3
On Thu, Oct 8, 2009 at 8:24 AM, Garrett D'Amore - sun microsystems
wrote:
> I'm submitting the following *full* case on my own behalf.
>
> Note that I'm not filing using the "normal" 20q format. ?I think this case
> will be easier to understand without it. ?The major concerns raised in
> this case
Peter Tribble wrote:
> On Thu, Oct 8, 2009 at 3:40 PM, Garrett D'Amore wrote:
>
>> Okay, corrected I stand. Although I *suspect* this problem could be
>> corrected too. The library is coming in via the libc, not via the
>> application pulling it in directly. (So if the relevant 4lib librarie
Joerg Schilling wrote:
> "Garrett D'Amore" wrote:
>
>
>> Okay, corrected I stand. Although I *suspect* this problem could be
>> corrected too. The library is coming in via the libc, not via the
>> application pulling it in directly. (So if the relevant 4lib libraries
>> were compiled to u
Okay, corrected I stand. Although I *suspect* this problem could be
corrected too. The library is coming in via the libc, not via the
application pulling it in directly. (So if the relevant 4lib libraries
were compiled to use normal libc, or got the important bits of libucb
linked in directl
Actually, looking at the code, I don't see how /usr/ucblib is used by
4.x *binaries*. I.e. if you have a SunOS 4.x binary, it looks like you
get the libraries in /usr/4lib, using the a.out exec module. I don't
think you wind up using any of the ELF stuff in /usr/ucblib.
So, maybe I didn't nam
Peter Tribble wrote:
> On Thu, Oct 8, 2009 at 8:24 AM, Garrett D'Amore - sun microsystems
> wrote:
>
>> I'm submitting the following *full* case on my own behalf.
>>
>> Note that I'm not filing using the "normal" 20q format. I think this case
>> will be easier to understand without it. The ma
> Note also that users who might still have such ancient hardware (or want
> to plot to a terminal device) might find they are able to plot to it using
> the "gnuplot" command, which has output drivers for it. (Gnuplot is not yet
> integrated, but this is expected as it was approved as part of PSAR
I am sponsoring this case on behalf of Yanmin Sun. This case seeks
micro/patch binding. Timeout is 10/15/09.
The case introduces new FMA events and a new fmd plug-in module
supporting the Nehalem_EX architecture. From the ARC perspective,
this case is mostly about carving out a piece of the FMA
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Increase the maximum value of NGROUPS_MAX to 1024
1.2. Name of Document Author/Supplier:
Author: Casper Dik
1
I'm submitting the following *full* case on my own behalf.
Note that I'm not filing using the "normal" 20q format. I think this case
will be easier to understand without it. The major concerns raised in
this case have to do with our compatibility guarantees, which is why this
case must be handl
35 matches
Mail list logo
