Rainer Orth wrote:
on its way out), the main offenders are SUNWonmtst.i (which only lacks
usr/bin/mtst, and could perhaps be opened) and SUNWiotu (which lacks
usr/sbin/pcitool and the corresponding man page).
Yup. I would ignore smartcard for now since it's slated to be removed
soon. usr/bin/mt
Peter,
> > On the other hand, I wonder why this cannot be dealt with in
> > usr/src/Targetdirs. I don't really understand which directories are
> > listed/created there and which are created only by other Makefiles.
>
> Don't feel bad, I don't think anyone really understands this ;-)
I'm gla
> On the other hand, I wonder why this cannot be dealt with in
> usr/src/Targetdirs. I don't really understand which directories are
> listed/created there and which are created only by other Makefiles.
Don't feel bad, I don't think anyone really understands this ;-)
In general, I think the
Stephen,
> Rainer Orth wrote:
> > Files missing from the proto area:
> >
> > T File Name Reloc/Sym name perm owner group
> > inode lnk maj min package(s)
> >
>
Stephen,
> This was a bug in my bindrop script when I wrote my first pass at
> cleaning up empty directories. I've got a new version of that code to
> create the closed-bins tarball, and etc/llc2/default made it back in for
> the 20060710 (today's) delivery. Could you try this again?
s
Keith M Wesolowski wrote:
Despite the low cost, I just don't see anything positive about this
feature.
The only benefit I see is it can ease porting of code that assumes
the behaviour. I've been through this several times and thanks to
[EMAIL PROTECTED] I've discovered it is buggy source code
On Tue, 11 Jul 2006, Michael Corcoran wrote:
Ryan,
Without a corefile, it's hard to say for sure, but this exact stack back
trace is also listed in CR 6315232 which was closed as a duplicate of
6223281 which was closed as a duplicate of 6286341 which made it into an
earlier version of S10.
I'
On Tue, Jul 11, 2006 at 12:14:59AM -0700, Padraig O'Briain wrote:
> I have submitted patches to various projects to change references to string
> variables which could be NULL from
>
> s to
>
> s ? s : "NULL"
Why? Other than debugging, what possible value does "NULL" have to
users besides tha
Ryan,
Without a corefile, it's hard to say for sure, but this exact stack back
trace is also listed in CR 6315232 which was closed as a duplicate of
6223281 which was closed as a duplicate of 6286341 which made it into an
earlier version of S10.
I'm assuming it's impossible to get a core file?
>Hello.
>
>I have a question on SSE registers use in
>/on/usr/src/lib/libc/i386_hwcap1/gen/memcpy.s. The code seems to use
>%xmm0, and other SSE registers without saving them before use.
>(.sse_sa_loop for example.)
>
>Wouldn't this cause trouble if a user was using SSE registers in their
>applica
Hello.
I have a question on SSE registers use in
/on/usr/src/lib/libc/i386_hwcap1/gen/memcpy.s. The code seems to use
%xmm0, and other SSE registers without saving them before use.
(.sse_sa_loop for example.)
Wouldn't this cause trouble if a user was using SSE registers in their
application?
Or
Rainer Orth wrote:
Files missing from the proto area:
T File Name Reloc/Sym name perm owner group inode
lnk maj min package(s)
d etc/llc2/default
Gavin Maltby wrote:
Hi
On 07/11/06 07:19, Oliver Yang wrote:
I have a question about last member of kmem_cache structure.
Why the elements number of cache_cpu is 1 as below definition, but on
SMP system, it's actual elements number is equal to the cpu numbers?
233 struct kmem_cache {
Hi
On 07/11/06 07:19, Oliver Yang wrote:
I have a question about last member of kmem_cache structure.
Why the elements number of cache_cpu is 1 as below definition, but on
SMP system, it's actual elements number is equal to the cpu numbers?
233 struct kmem_cache {
.
I have submitted patches to various projects to change references to string
variables which could be NULL from
s to
s ? s : "NULL"
I have looked in the code and found
http://cvs.opensolaris.org/source/xref/on/usr/src/common/util/string.c#172
which I think is what Linux is doing.
Most of the c
15 matches
Mail list logo