[osol-discuss] For sell Brand New Nokia N93 Nokia N95 Nintedo wii 60GB Sony Ps3 Dopod 900

[britton jullen]

We sell all kinds of mobile phones at very cheap price and also we sell at 
whole sales a good buyer should contact us through our contact address.

MOBILE PHONES:
Nokia N93...$250usd
Nokia N95...$350usd
Nokia N70...$160usd
Nokia N71...$160usd
Nokia N72...$200usd
Nokia N73...$180usd
Nokia N90...$180usd
Nokia N91...$200usd
Nokia n92...$220usd
Nokia n80...$180usd 
Nokia 6682..$160usd
Nokia 6830..$130usd
Nokia 7700..$130usd
Nokia 8100..$155usd
Nokia 8800..$180usd
Nokia 8801..$300usd
Nokia 8910i..$160usd
Nokia 9210i..$160usd
Nokia 9300...$160usd
Nokia 9500..$180usd
Nokia N Gage QD..$140usd
Nokia 7360...$165USD
Nokia 7380$175USD
Nokia 7370$170USD
Nokia 7710...$145USD 
Nokia 7610...$120usd
O2 X3...$180usd
O2 X4...$200usd
O2 XDA2.$180usd
O2 XDA2i$160usd
O2 XDA2s$145usd
O2 3G Datacard.$130usd
Orange Blackberry$250usd
Orange 3G Datacard...$200usd 
Orange SPV C500...$140usd
Orange SPV M2000.$120usd
Panasonic X60$120usd
Panasonic X70$125usd
Panasonic X300...$120usd
Panasonic X700...$150usd
Samsung z710.$280usd 
Samsung M8000$250usd
Samsung D410.$150usd
Samsung D600.$200usd
Samsung d500.$190usd
Samsung E310.$140usd
Samsung E330.$140usd
Samsung E600.$130usd 
Samsung E630.$130usd
Samsung E700.$135usd
Samsung E720.$140usd
Samsung D800..210USD
Samsung D820..220USD
Samsung D500.$160usd
Samsung d600.$170usd 
SIDEKICK 2..120USD
SIDEKICK 3..200USD
LG 8150..150usd
LG 8150..140usd
LG G8000..130usd
MDA4..130usd
Mitac MIO 8930..$250usd
Motorola A600...$146usd 
Motorola A630...$148usd
Motorola A760...$150usd
Motorola A780...$154usd
Motorola A840...$162usd
Motorola E1.$134usd
Motorola MPX$125usd
Motorola MPX100.$120usd
Motorola MPX300.,...$115usd
Motorola razor v3.$130usd
Motorola razor v3 pink edition$130usd
Motorola v3X..140usd
Motorola MPX300.,...$150usd
Motorola V3i..150usd
Motorola L7..140USD 
Nextel i930.$130usd
Nextel i870.$120usd
Nextel i860.$110usd
Sony Ericsson w900i$240usd
Sony Ericsson W800i$200usd
sony Ericsson w700.$180usd
sony Ericsson w600i$165usd 
sony Ericsson w300.$150usd
sony Ericsson w950.$220usd
Sony Ericsson p990i$205usd
Sony Ericsson m600i.$200usd
sony Ericsson m600.$170usd
Sony Ericsson p990.$210usd
Sony Ericsson p910i$200usd 
Treo 710...$250usd
Treo 700...$220usd
Treo 600...$170usd
Treo 650...$190usd
Toshiba Satellite PRO L10 $320
Toshiba M200 $500
Toshiba R100 $450 
Toshiba Qosmio E10 $750 
Toshiba Satellite PRO L20 $250
Toshiba M100 $680
Toshiba M300 $740
Toshiba Portege A200 $320
Toshiba Satellite L10 $330
Toshiba Qosmio F20 $500 
Dell Laptops
Dell Latitude D600 $290 
Dell Latitude D500 t $200 
Dell Inspiron 6000 $350
Dell Latitude D505 $340
Dell Latitude D610 $460
Dell Latitude D510 $320
Dell Inspiron 9300 $530 
Sony Laptops
Sony VAIO VGN-T1 $680
Sony VAIO VGN-FS315 $420 
Sony VAIO VGN-S3 $450 
Sony VAIO VGN-TX1 $840
Sony VAIO VGN-FS215 $ 310
Sony VAIO VGN-S4 $470
Sony VAIO PCG-K35 $550
contact us today

E-mail:[EMAIL PROTECTED] 
[EMAIL PROTECTED] 
tel:+2348023986539 
tel:+23418949371
Thanks.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] Re: Its 2007, with an article vi on slashdot ?

[UNIX admin]

> I still own a PDP 11 Front panel with purple switches
> and a 4K core memory board :-)

Does it run UNICS? (:-)
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] Re: Its 2007, with an article vi on slashdot ?

[UNIX admin]

> Interestingly, all 3 of the above are based on
> variants of the venerable 6502.
> Z80s were for pansies!  :-)

HAHA, yo, 6502s are forever!

LDA #$37
STA $01
CLI
RTS

(:-)
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] Re: Its 2007, with an article vi on slashdot ?

[UNIX admin]

> For the record, I use vi.  Not just any vi either but
> THE vi in
> /usr/xpg4/bin/vi and I set my env var EDITOR that way
> too.

`vi` has this property that it can become ingrained in one's "muscle memory". 
And once that happens, one starts punching in `vi` keystrokes... in any editor. 
Can't imagine how I ever did without `vi`.

> Oh .. don't know if anyone knows this bit of trivia
> in the Solaris world but
> Rich Teer wrote his massive 1152 page book, "Solaris
> Systems Programming" in
> the time honoured tradition of using vi and troff.
>  It says so on page
> xxvi.[1]

Yep, he wrote something along those lines back then when he was writing the 
book; I remember that.
Personally, I find `troff` te be a fascinating tool.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] Re: Its 2007, with an article vi on slashdot ?

[UNIX admin]

> That
> was an awesome release of
> Solaris and I still have it installed and running on
> a P90 here.  That would
> be Solaris 2.5.1 for x86 back when people sneered at
> *that* like it was a joke.

I ran Solaris 2.5.1 for i86pc when it first came out on a P90, and was amazed 
at how fast and responsive the system was (I ran OpenWindows on it). The only 
major suck was lack of Netscape for Solaris i86pc release.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Project Proposal: Enhance the support of USB webcams

[Darren J Moffat]

Colin Zou wrote:
This project will deliver a set of userland libs and applications, and 
maybe some small patches to the existing USB webcam drivers.


+1

--
Darren J Moffat
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Obtaining nameservice-independent "user_attr" and"publickey" data from a shell script ?

[Darren J Moffat]

Roland Mainz wrote:

Darren J Moffat wrote:

Roland Mainz wrote:

Is there a nameservice-independent way to obtain the values for
"user_attr" and "publickey" from a shell script (if not I would propose
to add a extension to "getent") ?

publickey no there isn't.

For user_attr it depends which values you want.


I want the "raw" values as returned by |getuserattr()|, |getprofattr()|,
|getprofattr()| etc. ... /usr/bin/getent should just return the matching
values, either for the admins, users or shell script to use.


As long as you understand that you can NOT use the data from 
user_attr(4) on its own it MUST be used in conjunction with prof_attr(4) 
and exec_attr(4) in some cases.



Possible usage would be a system admin to figure out whether the system
"sees" the changed attributes in a way he/she would expect it (e.g.
change/modification verification) ... 


For the cases that auths(1), profiles(1), roles(1) cover it is actually 
better to use those because those tell you what the applications that 
use the data see not what the raw entry in the nameservice is.


Having said that I completely agree with you that for every entry in 
nsswitch.conf there should be a corresponding getent capability.


--
Darren J Moffat
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Obtaining nameservice-independent "user_attr"and"publickey" data from a shell script ?

[James Carlson]

Roland Mainz writes:
> > It sounds like part of a decent RFE to me.
> 
> Ouch... and how would the implementation look like ? The idea was to get
> simple access to the data independent of the backend nameservice
> details, e.g. a script should not need to implement support for YP,
> NIS+, LDAP etc. seperately. Adding those switches would make this MUCH
> more painfull to implement since we could no longer use any library
> functions and instead have to do our own lookup code in /usr/bin/getent
> ... and that's AFAIK an overkill...

Replicating the name service logic itself into getent would indeed be
a foolish way to do this.  I don't think it'd be as much overkill as
it would be bad design.

The implementation I was assuming here would most likely include
adding interfaces into the name service logic to allow the application
to override the nsswitch.conf settings.  This obviously has
implications for the caching mechanism, but I've always felt that was
done at the wrong layer in the architecture anyway.

-- 
James Carlson, KISS Network<[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] Re: Project Proposal: Enhance the support of USB webcams

[Richard Skelton]

> This project will deliver a set of userland libs and
> applications, and maybe 
> some small patches to the existing USB webcam
> drivers.
> 
> Colin Zou
> ___
> opensolaris-discuss mailing list
> opensolaris-discuss@opensolaris.org
> 

+1

Cheers
Richard.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Project Proposal: Enhance the support of USB webcams

[Joey Guo]

Colin Zou wrote:
> This project will deliver a set of userland libs and applications, and
> maybe some small patches to the existing USB webcam drivers.
>
> USB webcams are popular now, they are widely used in desktop/laptop
> systems. Some video applications, like video conferencing, can not
> work without these devices.
>
> At present, USB webcam drivers running in OS kernel support some basic
> webcam functions, like read video stream from the device, issue some
> video control commands to the device, decode video formats, etc.
> However, it is too difficult to develop/update kernel drivers to
> support all the fancy features from webcam vendors. Some new features
> (like face tracing, pan, etc.) are vendor specific, and people need
> implementing proprietary algorithms to support them. Therefore, it is
> not easy to support these features in kernel drivers, especially in
> class drivers.
>
> To further illustrate the problem, let's take USB video class spec
> (see usb.org) as an example. This class spec defines common video
> interfaces that a USB webcam may have, but these interfaces can not
> cover the new features mentioned above. From the hardware view, the
> spec does allow webcam vendors to extend their own fancy features by
> implementing some extra functions in the device. From the software
> view, although webcam vendors can write their own device drivers to
> support the fancy features, it is really a tough task to re-write a
> kernel driver. A much better choice is, keeping the kernel driver
> untouched or making only slight modifications to the kernel driver,
> instead, we implement the vendor specific features in userland libs
> and applications.
>
> The first stage of this project will focus on supporting some Logitech
> webcams. Because they are popular in the market and there are several
> models of them are compliant to USB video class spec. There is a usb
> video class driver available for these class compliant webcams, so
> some basic video features are already supported by the driver. It is
> feasible to enhance the support of the webcams complaint to USB video
> class spec first.
>
> Communities this project is related to: Device Drivers, Desktop, Laptop.
>
> Colin Zou
> ___
> opensolaris-discuss mailing list
> opensolaris-discuss@opensolaris.org
+1.

Great work, Colin!

-- 
Joey Guo, University Program Manager
Sun China Engineering & Research Institute
http://eri.prc.sun.com/wiki/univ
http://blogs.sun.com/JoeyGuo
Tel:(86)10-82618200-82245
Mobile: (86)13391817372


___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] Telnet sesions disconnected after few seconds!!!

[Gabriel Tabac]

Hello to all,

I have a problem with telnet session. I log on with a telnet session to a Sun 
Solaris server with a read permission user. After few seconds (various period, 
not a fix timer)  I'm automatically log out. This is a general problem because 
my colleagues have this problem too. Can you help me with this problem???
Thank you in advance!!!

Gaby
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] .profile not executing

[Brian Leonard]

For some reason my .profile does not execute when I log into Solaris. Only 
after I su to myself from   a terminal window:

su - bleonard

do I get my environment settings. What silly thing am I doing wrong?

Thanks,
Brian
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] Re: Help needed with "mpathadm:Error: Unable to get configuration info" e

[Leon Koll]

did it, got MP_DRVR_INVALID_ID :

<...>
Jan  8 17:09:01 binas1 mpathadm[19430]: [ID 301755 user.debug] MP-API (SUN) 
Plugin: MP_GetMPLogicalUnitProperties(): oid.objectSequenceNumber = 7
Jan  8 17:09:01 binas1 mpathadm[19430]: [ID 978213 user.debug] MP-API (SUN) 
Plugin: MP_GetMPLogicalUnitProperties():  IOCTL call returned: -1
Jan  8 17:09:01 binas1 mpathadm[19430]: [ID 951295 user.debug] MP-API (SUN) 
Plugin: MP_GetMPLogicalUnitProperties(): IOCTL call failed.  IOCTL error is: 22
Jan  8 17:09:01 binas1 mpathadm[19430]: [ID 883528 user.debug] MP-API (SUN) 
Plugin: MP_GetMPLogicalUnitProperties(): IOCTL call failed.  IOCTL error is: In
valid argument
Jan  8 17:09:01 binas1 mpathadm[19430]: [ID 694429 user.debug] MP-API (SUN) 
Plugin: MP_GetMPLogicalUnitProperties(): IOCTL call failed.  mp_ioctl.mp_errno:
 5535
Jan  8 17:09:01 binas1 mpathadm[19430]: [ID 651305 user.debug] MP-API (SUN) 
Plugin: getStatus4ErrorCode(): - enter
Jan  8 17:09:01 binas1 mpathadm[19430]: [ID 163903 user.debug] MP-API (SUN) 
Plugin: getStatus4ErrorCode():  received mp_errno=MP_DRVR_INVALID_ID from drive
r call.
Jan  8 17:09:01 binas1 mpathadm[19430]: [ID 389051 user.debug] MP-API (SUN) 
Plugin: getStatus4ErrorCode():  returning MP_STATUS_OBJECT_NOT_FOUND to caller.
Jan  8 17:09:01 binas1 mpathadm[19430]: [ID 991081 user.debug] MP-API (SUN) 
Plugin: getStatus4ErrorCode(): - exit
Jan  8 17:09:01 binas1 mpathadm[19430]: [ID 302736 user.debug] MP-API (SUN) 
Plugin: MP_GetMPLogicalUnitProperties():  - error exit
Jan  8 17:09:01 binas1 mpathadm[19430]: [ID 241278 user.debug] MP-API (SUN) 
Plugin: Terminate():  - enter
Jan  8 17:09:01 binas1 mpathadm[19430]: [ID 338080 user.debug] MP-API (SUN) 
Plugin: Terminate():  - exit

full info here: http://tinyurl.com/y8mklc

What does this MP_DRVR_INVALID_ID mean? 

tia,
-- leon
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] .profile not executing

[Darren J Moffat]

Brian Leonard wrote:

For some reason my .profile does not execute when I log into Solaris. Only 
after I su to myself from   a terminal window:

su - bleonard

do I get my environment settings. What silly thing am I doing wrong?


What shell is set for you ?
What program is being used to login ?
dtlogin, gdm, ssh, telnet, rlogin ?
If dtlogin or gdm what graphical window system are you using ?
CDE, GNOME (aka JDS) other ?
What terminal program are you using ?
xterm, dtterm, gnome-terminal ?


--
Darren J Moffat
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] How to find the number of cores on T1 processor

[Nikolay Piskun]

I think this is more general for all processors, but I am mostly interested in 
T1 which is 8 core 32 virtual processors. The question is, is there any 
function call, that returns the number of cores instead of the number of 
virtual processors.
Thanks,
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] .profile not executing

[Brian Leonard]

Hi Darren,

Yes, all good to know, sorry :-).


What shell is set for you ?

bash

What program is being used to login ?
dtlogin, gdm, ssh, telnet, rlogin ?
This isn't clear to me. Solaris boots up and I login. I'm guessing 
dtlogin or gdm as I'm using GNOME.

If dtlogin or gdm what graphical window system are you using ?
CDE, GNOME (aka JDS) other ?

GNOME

What terminal program are you using ?
xterm, dtterm, gnome-terminal ?

gnome-terminal.

/Brian


___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Re: Shipping "lsof" with Solaris ? / was: Re: problem with /t

[a b]

If you postulate that

1) lsof is tightly bound to a particular kernel build,

2) lsof behaves correctly on the kernel it was built for, and

3) lsof will be rebuilt and redelivered in concert with
  any and all new kernel builds

then there is no architectural problem with what your colleague suggests.
We tend to call such things "consolidation private dependencies" and
gleefully (for the ARCs at least) delegate the job of keeping the
producer (kernel) and consumer (lsof) working correctly to the people who
are responsible for delivering the consolidation itself...

Of course, if you can't guarantee #2 above, this won't work.


Just having to compile `lsof` every time the kernel rev changes is already 
too much overhead. At any given day, there are many issues, feature requests 
and fixes to the build, that it is really inefficient to have one more thing 
to worry about -- some crappy utility written by an external 3rd party whose 
only benefit is to show open ports and files.


Unacceptable, and certainly not worth the overhead. If this was a quality 
piece of software, then my stance would be entirely different.


Lastly, if this `lsof` thing is peeking into private kernel structs which 
might not be there any more, or work differently, a recompile won't help. So 
the whole thing is stillborn. I'm definitely going to fight tooth and nail 
to *not* have crappy software like that integrated into the build.


My stance is: either write quality software, or it's time to change the 
profession. And that stance of mine goes toward the gentleman that wrote 
`lsof` as well!


_
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

RE: Shipping "lsof" with Solaris ? / was: Re: [osol-discuss] problem with /tmp FS still up

[Vic Abell]

Josh, Rich, et al.,

> On 1/5/07, Rich Teer <[EMAIL PROTECTED]> wrote:
> > On Fri, 5 Jan 2007, Christoph Hellwig wrote:
> >
> > > Note that lsof doesn't have to do kmem craling.  For 
> example on Linux
> > > it only uses proper procfs interfaces.  As such proper 
> interfaces seem
> > > to exist on Solaris as well for use with pfiles it 
> shouldn't be a problem
> > > for people knowledgeable in this area to adjust lsof to 
> do the right
> > > thin on Solaris aswell.
> >
> > Have we invited Vic Abel
> 
> Vic's name is spelled 'Abell', two e-

I've been called worse.  :-)  No apology is necessary, Rich.
 
> > (lsof's author) to join the OpenSolaris
> > community?  With the right support framework in place, he'd probably
> > be the best person to make the required changes (in lsof anyway).
> 
> Better: Sun could hire him!

I am very happily retired and not looking for employment.

But let me explain why lsof has continued to use /dev/kmem.

The foremost reason is that I can test it as a guest on systems
where I couldn't (or wouldn't want to) have root permission.  Sys
group membership is all I need and most administrators are willing
to give that with a guest login.  (I also have a innate distaste for
setuid(root) programs.)

There are other reasons, however.  On Linux, for example, which
was cited as prototypical reason for using the Solaris /proc,
lsof isn't fully capable in one important respect, because of
a deficiency in the Linux /proc file system.  It can't deliver
current file position (as found in the file structure), so lsof
can't report it, something I have found extremely valuable when
using lsof to watch a file's progress -- e.g., growth.

A second example is the HP-UX PSTAT extensions for lsof in
whose development I played a direct role.  Bugs have surfaced
in that interface over the several years lsof has been using
it and one significant one has been the subject of considerable
discussion between me, customers and HP.  After over a year of
that, I think the bug may have finally been accepted as a bug
and may even get fixed.

Those two examples show that API's have their own limitations,
primarily sluggish response to necessary fixes.  At one time I
proposed to Sun the construction of an lsof API for Solaris,
but that proposal never went anywhere.  I made it right after
completing the HP PSTAT API, thinking its existence might be a
sufficient prod.  Now that I have struggled getting HP to fix
a simple PSTAT bug for a year, my enchantment with lsof APIs
has lost some of its edge.

Having said all that, I would be interested in joining in some
sort of effort to make lsof a part of OpenSolaris.

Regards,

Vic Abell, lsof author

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Re: rpm vs pkgadd (again!)

[a b]

If there's one way in which I've been fortunate recently, it's that I no
longer
have to deal with the monstrosity that is inst. Anything that can get so
tangled up that it cannot allow you to install some software because of
irreconcilable dependencies is something I'm glad to be rid of. (Although
I have seen rpm based machines go into the same abyss.)


`inst` is an extremely intelligent and elegant software management 
subsystem, but it still doesn't have the kind of intelligence that 
automatically detects and corrects the oversights made by the packager; I 
should know, since I used to create IRIX dists and .tardists.


Did you ever look at the packaging mechanisms and architecture employed in 
`inst`? It's mind blowing, to say the least, how SGI solved some of the most 
complex problems in a simple, elegant way.


The tool is almost 20 years old, but it's so ahead of its time that it can 
still be *the* standard against which all other software subsystems are 
measured.


If you don't believe me, look at the nitty-gritty details at 
http://techpubs.sgi.com/.


_
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] How to find the number of cores on T1 processor

[Darren J Moffat]

Nikolay Piskun wrote:

I think this is more general for all processors, but I am mostly interested in 
T1 which is 8 core 32 virtual processors. The question is, is there any 
function call, that returns the number of cores instead of the number of 
virtual processors.


What exactly are you planning on doing with this information ?

This can be done, see the implementation of psrinfo:

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/psrinfo/psrinfo.pl

--
Darren J Moffat
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Re: Shipping "lsof" with Solaris ? / was: Re: problem with /t

[Dave Marquardt]

"a" == a b  writes:

>> If you postulate that
>> 
>> 1) lsof is tightly bound to a particular kernel build,
>> 
>> 2) lsof behaves correctly on the kernel it was built for, and
>> 
>> 3) lsof will be rebuilt and redelivered in concert with
>> any and all new kernel builds
>> 
>> then there is no architectural problem with what your colleague suggests.
>> We tend to call such things "consolidation private dependencies" and
>> gleefully (for the ARCs at least) delegate the job of keeping the
>> producer (kernel) and consumer (lsof) working correctly to the people who
>> are responsible for delivering the consolidation itself...
>> 
>> Of course, if you can't guarantee #2 above, this won't work.

a> Just having to compile `lsof` every time the kernel rev changes is already
a> too much overhead. At any given day, there are many issues, feature
a> requests and fixes to the build, that it is really inefficient to have one
a> more thing to worry about -- some crappy utility written by an external 3rd
a> party whose only benefit is to show open ports and files.

It occurred to me that we might be able to leverage the CTF
information that mdb uses to decode structures in the kernel.
Unfortunately, last I looked, the CTF lookup code in mdb was not a
public interface, so I'm not sure we can go there at this point.  But
if we could, then we could use CTF to look up the structure definition
and avoid recompiling lsof (or some similar program).
-- 
Dave Marquardt
Sun Microsystems, Inc.
Austin, TX
+1 512 401-1077 (SUN internal: x64077)
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Re: Shipping "lsof" with Solaris ? / was: Re: problem with /t

[James Carlson]

a b writes:
> Just having to compile `lsof` every time the kernel rev changes is already 
> too much overhead.

That's precisely what happens when something is part of the ON
consolidation.  That's actually a fairly good reason to argue *for*
integrating lsof into ON -- it gets recompiled every time the kernel
itself is compiled.

The argument against it is that even though use of private interfaces
inside the same consolidation is permitted, using "too many" of them
causes a entanglement that's unmaintainable.  It forces those working
in other areas to maintain lsof as well.  That's the argument for
having as many better (more deliberate) interfaces as possible.

> At any given day, there are many issues, feature requests 
> and fixes to the build, that it is really inefficient to have one more thing 
> to worry about -- some crappy utility written by an external 3rd party whose 
> only benefit is to show open ports and files.

Wow.  I sure don't feel that way, nor do I think anyone who has ever
suffered from a mysterious open port or a rapidly growing log file
would feel that way about it.

-- 
James Carlson, Solaris Networking  <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] Re: How to find the number of cores on T1 processor

[Nikolay Piskun]

I am trying to implement in C++ something like what I get from: 
kstat -m cpu_info | grep core_id
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Re: Shipping "lsof" with Solaris ? / was: Re: problem with /t

[John Plocher]

a b wrote:

3) lsof will be rebuilt and redelivered in concert with
  any and all new kernel builds

then there is no architectural problem 


Just having to compile `lsof` every time the kernel rev changes is 
already too much overhead.


If you (or your peers at work) are not able or willing to retest
and redeliver lsof every time the kernel rev changes, then you
(obviously) do not have a viable plan to include lsof into your
local OpenSolaris builds.

My point was that the requirement to keep it up to date is a
fundamental part of putting it "in" .  If you have a commitment
to do that work, then the risks can be managed.  Without it,
they can't.

If its architecture/design is such that it can't coexist easily
with the rest of the system, or if it is too chaotic to sustain,
then it follows that it is too chaotic to integrate in the first
place

   -John
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [install-discuss] Re: [osol-discuss] rpm vs pkgadd (again!)

[Laszlo (Laca) Peter]

On Fri, 2007-01-05 at 13:43 -0500, James Carlson wrote:

> > One feature that's missing, and would be infinitely useful for
> > online package repositories, is >= style version checking in
> > dependencies.  E.g. if I have an xchat package that was compiled
> > against GNOME 2.16, I'd like to say in the depend file that it
> > needs SUNWgnome-base-libs >= 2.16.0.
> 
> It's not missing from the underlying packaging standards -- see
> pkginfo(4) and depend(4).

I know you can specify a list of versions for each dependency, but
you can do anything more flexible.  I've just tried and even the
REV must match otherwise pkgadd complains.  This make this feature
completely unusable.  (Unless I missed something in the man page).

> Historically, we've taken a different approach here.  Instead of
> attempting to handle these microscopic dependencies (which, at least
> in my experience, although "obvious" from the outset, quickly become
> quite unwieldy in practice), we rest the software stability on a set
> of architectural rules.  Among those are:
>
>   - If you rely on something special, then it's up to you to arrange
> for simultaneous delivery of that 'something' so that customers
> aren't left scrambling to figure out how to use your software.
> (E.g., by patch dependencies and/or by special install scripts.)
>
>   - Incompatible and disruptive change occurs only in particular kinds
> of (relatively infrequent) releases.

These rules work great for an integrated product like Solaris.
But if I want to provide Solaris-compatible packages for download,
how do I verify that the dependencies are the correct versions?
For example, if I offer a binary package of XChat for download,
and it was built against snv_53's GNOME 2.16, it'll work fine on
2.16 and later but unlikely to work on snv_52, which had GNOME 2.14.
Compatibility is not working in that direction.

I'd like to say something like

P SUNWgnome-base-libs
  (i386) >= 2.16.0
I SUNWgnome-base-libs
  (i386) >= 3

i.e. my package will work with GNOME 2 version 2.16 or later but
won't work with GNOME 3, because that's a major version change.

Laca


___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Re: rpm vs pkgadd (again!)

[Laszlo (Laca) Peter]

On Fri, 2007-01-05 at 18:45 -0800, Peter C. Norton wrote:
> 5) Rpm is rpmbuild as well.  Though you don't have to use it to build
>the software and the package, it's a lot easier and usually a good
>discipline because it automates much of the process. 

pkgbuild intends to be rpmbuild for Solaris.
See http://pkgbuild.sf.net
JDS is built with pkgbuild.

> 1) Upon package creating, the tools automatically scan for known
>dependancy types. dynamic libaries are scanned for symbol names and
>versions (as supplied by the linker, I guess), perl, python and
>concievably other interpreters will be scanned for statements that
>indicate dependancy such as "use" in perl, or "import" in python.

pkgbuild doesn't do this yet, but "autoreqprovider" is on my todo list.
It won't be too difficult if I re-use Alan Coopersmith's check_deps
script.

Laca


___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [install-discuss] Re: [osol-discuss] rpm vs pkgadd (again!)

[James Carlson]

Laszlo (Laca) Peter writes:
> On Fri, 2007-01-05 at 13:43 -0500, James Carlson wrote:
> 
> > > One feature that's missing, and would be infinitely useful for
> > > online package repositories, is >= style version checking in
> > > dependencies.  E.g. if I have an xchat package that was compiled
> > > against GNOME 2.16, I'd like to say in the depend file that it
> > > needs SUNWgnome-base-libs >= 2.16.0.
> > 
> > It's not missing from the underlying packaging standards -- see
> > pkginfo(4) and depend(4).
> 
> I know you can specify a list of versions for each dependency, but
> you can do anything more flexible.  I've just tried and even the
> REV must match otherwise pkgadd complains.  This make this feature
> completely unusable.  (Unless I missed something in the man page).

Yes; it's essentially an exact match.

> >   - Incompatible and disruptive change occurs only in particular kinds
> > of (relatively infrequent) releases.
> 
> These rules work great for an integrated product like Solaris.
> But if I want to provide Solaris-compatible packages for download,
> how do I verify that the dependencies are the correct versions?

Build on the oldest version you want to support, because we
intentionally support backward compatibility.

> For example, if I offer a binary package of XChat for download,
> and it was built against snv_53's GNOME 2.16, it'll work fine on
> 2.16 and later but unlikely to work on snv_52, which had GNOME 2.14.
> Compatibility is not working in that direction.

It turns out that snv_52 and snv_53 aren't themselves releases so the
issue is moot.  But perhaps that point doesn't matter here.

The existing rule is that you need to build on a system that is at
least as old as what you plan to support.  You can then test for that
minimum system version and (because libraries are carefully designed
to be stable ;-}) run on any newer version.

> I'd like to say something like
> 
> P SUNWgnome-base-libs
>   (i386) >= 2.16.0
> I SUNWgnome-base-libs
>   (i386) >= 3
> 
> i.e. my package will work with GNOME 2 version 2.16 or later but
> won't work with GNOME 3, because that's a major version change.

The original point above was about avoiding microscopic versioning
because it tends to be difficult to maintain over time.

I understand the request, and it's not an unfamiliar one, but it's
just plain different from the direction Solaris had been going.  To do
something like that, someone's going to have to work out just how
complex these entanglements can be and what the (new) software
delivery rules are.  It's not intuitively obvious, at least to me.

I'd very much like to see Solaris avoid the mutually-exclusive
dependency horror show I saw with apt on Debian ... shortly before I
switched away.  I realize the existing system doesn't support what
*everyone* wants to do, but in adding new features, we do have to be
careful to avoid wrecking existing simplicity.

-- 
James Carlson, Solaris Networking  <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Debug the Dynamic Linker

[Rod Evans]

DEEPAK BHATIA wrote:


Can anyone please suggest how to proceed ? How do I tell the OS to invoke my 
dynamic linker instead of the original one.


You can explicitly invoke a different runtime linker:

oxpoly 428. cp /usr/lib/ld.so.1 /tmp/ld.so.1
oxpoly 429. /tmp/ld.so.1 /bin/cat &
[1] 17398
oxpoly 430. pmap 17398
17398:  /tmp/ld.so.1 /bin/cat
0001  16K r-x--  /usr/bin/cat
00024000   8K rwx--  /usr/bin/cat

FF3B 208K r-x--  /tmp/ld.so.1
FF3F4000   8K rwx--  /tmp/ld.so.1

You can also embed the name of a non-default runtime linker
within an application:

oxpoly 435. LD_OPTIONS=-I/tmp/ld.so.1 cc -o main  main.c
oxpoly 436. elfdump -i main

Interpreter Section:  .interp
/tmp/ld.so.1

I use mdb(1) to debug ld.so.1, plus there are some helper functions
available from our mdb module.  See

  http://docs.sun.com/app/docs/doc/817-1984/6mhm7pl1k?a=view

And, don't forget printf's :-)  They are easy to add, and it takes
just seconds to rebuild ld.so.1.

--
Rod
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] Re: How to find the number of cores on T1 processor

[Nikolay Piskun]

I think I am close to find the answer, but I get stuck in kstat. 
I am using calls to kstat but after getting cpu_info kstat I don't know how to 
cast it to the right structure, that gives me core_id field. Here is my code: 
.
kstat_t *kp;
if (strncmp(kp->ks_name, "cpu_info", 8) == 0) {  
  kstat_read(kc, kp, NULL);
  printf("%d: %s\n",kp->ks_kid,kp->ks_name);  

cpu_stat_t*  statp = (cpu_stat_t *)(kp->ks_data);
Apparently last line doesn't  work.  

Any help will be appreciated.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [install-discuss] Re: [osol-discuss] rpm vs pkgadd (again!)

[Laszlo (Laca) Peter]

On Mon, 2007-01-08 at 13:57 -0500, James Carlson wrote:
> The existing rule is that you need to build on a system that is at
> least as old as what you plan to support.  You can then test for that
> minimum system version and (because libraries are carefully designed
> to be stable ;-}) run on any newer version.

Exactly.  But how do I express this as a package dependency?
In other words, what stops users from installing my package
on a system that is older than the oldest I plan to support?

Laca


___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [install-discuss] Re: [osol-discuss] rpm vs pkgadd (again!)

[James Carlson]

Laszlo (Laca) Peter writes:
> On Mon, 2007-01-08 at 13:57 -0500, James Carlson wrote:
> > The existing rule is that you need to build on a system that is at
> > least as old as what you plan to support.  You can then test for that
> > minimum system version and (because libraries are carefully designed
> > to be stable ;-}) run on any newer version.
> 
> Exactly.  But how do I express this as a package dependency?
> In other words, what stops users from installing my package
> on a system that is older than the oldest I plan to support?

If you avoid microscopic package versioning, you either tell customers
"supported on Solaris X and above" and be done with it, or (if you're
feeling pedantic) you test uname -r and the existence of the objects
(such as /usr/lib/libfoo.so.1) in question during a preinstall script.

For things on existing versions of Solaris, delivery of patches gives
you a richer way to express dependency, because of just this problem.
It's not well connected with packaging, though.

-- 
James Carlson, Solaris Networking  <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Re: How to find the number of cores on T1 processor

[Peter Tribble]

On 1/8/07, Nikolay Piskun <[EMAIL PROTECTED]> wrote:


I think I am close to find the answer, but I get stuck in kstat.
I am using calls to kstat but after getting cpu_info kstat I don't know
how to cast it to the right structure, that gives me core_id field. Here is
my code:
.
kstat_t *kp;
if (strncmp(kp->ks_name, "cpu_info", 8) == 0) {
  kstat_read(kc, kp, NULL);
  printf("%d: %s\n",kp->ks_kid,kp->ks_name);

cpu_stat_t*  statp = (cpu_stat_t *)(kp->ks_data);
Apparently last line doesn't  work.



It won't. The cpu_info kstats are of type KSTAT_TYPE_NAMED
which means the data is basically a hash with the name as the key,
and you use the kstat routines to access it.

You can pick the entry out with:

kstat_named_t* kn;
kn = kstat_data_lookup(kp, "core_id");

You then need to look at kn->data_type to work out what sort of value
the data is (signed, unsigned, 32bit, 64bit, string, char etc - look at
/usr/include/sys/kstat.h) or just guess that it's a long.

long core_id = kn->value.l;

--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] Re: .profile not executing

[Andrew Pattison]

Bash uses .bash_profile rather than .profile .

Cheers

Andrew.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] Project Proposal: PRESTO - Automatic Printing Configuration

[Norm Jacobs]

Inside of Sun, we have been looking at and discussing some of this for a
while now and we have posted information about this in the OpenSolaris
Printing Community portal, but we wanted to open this up to a wider
audience and see if we can't garner more interest and participation.  As
a result, I am proposing the creation of a new OpenSolaris Project to
address the ease and automation of printing related configuration
management.  Below is a brief description of what we are looking to
address.  Obviously, this is open to change based on input and
participation, but It's a place to start.

-Norm


  Purpose

To improve Solaris approachability, specifically the print service, by
automatically (or as automatically as possible) discovering and
configuring access to directly attached, network attached, and remotely
served printers.


  Key Goals

* Provide users with a more hands-off/automatic mechanism for using
  printers that they plug into their host or local network.
* Provide a mechanism for automatically recognizing and configuring
  access to existing print queues as they move across networks.
* Use SMF for managing network queue discovery/advertising services
* Tighter desktop integration.


  High Level Overview

Solaris includes a system event notification service that allows
applications to register and receive events that they are interested
in.  As part of the Tamarack Project
, the Hardware
Abstraction Layer 
(HAL), commonly used on Linux, has been integrated into Solaris.  It
will contains support for recognizing sysevent device add/remove events.

Support for directly attached printers will come in two varieties. 
First, there is the hot-plug variety where a device is plugged into an
interface or bus that is capable of detecting the event an propagating
it to the event notification service.  This applies to USB attached
printers.  Next, there is the traditional, polling variety where a
device is plugged into an interface that doesn't detect the printer
attachment/detachment, but instead requires the interface to be
periodically polled and then queried for information about the attached
device.  This applies to ecpp (parallel) printer interfaces.  Finally,
there are the polling variety that don't support a standard mechanism
for retrieving information about the attached device.  This would
include centronics parallel printers and serially attached printers. 
Devices attached through these interfaces are out of scope.

Support for for network attached printers will come from a variety of
sources.  Many of the newer models of printers available today provide
support for advertising their availability on the network via protocols
like mDNS and SLPv2.  When attached, these printers will broadcast (or
multicast) information about themselves to the local network.  Some
newer printers and most older printers are not capable of announcing
themselves to the network.  In order to detect their
attachment/detachment, a polling service must run somewhere on the local
network.

Support for finding available print queues on the network already exists
in Solaris in the form of network name service printer maps.  These maps
publish a list of "advertised" print queues that client systems can
access.  In a larger network with one or more dedicated administrators,
these maps are likely to be populated and reasonably current.  In a
home, small office, or ad hoc network environment, these maps are very
unlikely to exist.  As a result, a broadcast or multicast mechanism may
be a desirable alternative. Currently CUPS includes a broadcast print
queue advertisement capability that allows just such sharing.  Windows
and MacOS/X also provide something similar.  In order to provide maximal
interoperability, these mechanisms should be implemented instead of
inventing yet another mechanism.

Printers found through the system hot-plug support should be recognized
by HAL with some minor changes.  Polling and network printer detection
will require the addition of "add-on" module(s) or separate services
that tie into HAL.  Printer property probing will require the inclusion
of a printer probe program.

Once a printer has been "found" and probed  or removed by HAL, a D-BUS
 message for the
printer add/remove will be generated.  This message may be received in
the user's desktop session by a monitoring application.  This
application will then be able to notify user's of events and potentially
perform additional actions when those events occur.  For example,
plugging in a USB printer may cause a print queue to be created
automatically, it may launch a pre-filled add printer dialog, it may
provide a notification, or some combination of these actions.
___
opensolaris-discuss mailing list
opensolaris-discuss@o

Re: [osol-discuss] Re: How to find the number of cores on T1 processor

[Sean McGrath - Sun Microsystems Ireland]

Nikolay Piskun stated:
< I am trying to implement in C++ something like what I get from: 
< kstat -m cpu_info | grep core_id

  This article gives a decent intro into using libkstat
http://developers.sun.com/solaris/articles/kstatc.html

<  
<  
< This message posted from opensolaris.org
< ___
< opensolaris-discuss mailing list
< opensolaris-discuss@opensolaris.org

-- 
Sean.
.
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Project Proposal: PRESTO - Automatic Printing Configuration

[James Carlson]

Norm Jacobs writes:
> * Provide users with a more hands-off/automatic mechanism for using
>   printers that they plug into their host or local network.
> * Provide a mechanism for automatically recognizing and configuring
>   access to existing print queues as they move across networks.
> * Use SMF for managing network queue discovery/advertising services
> * Tighter desktop integration.

+1

-- 
James Carlson, Solaris Networking  <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Project Proposal: PRESTO - Automatic Printing Configuration

[Jan Spitalnik]

Hi,

Dne pondělí 08 leden 2007 21:47 Norm Jacobs napsal(a):
> Inside of Sun, we have been looking at and discussing some of this for a
> while now and we have posted information about this in the OpenSolaris
> Printing Community portal, but we wanted to open this up to a wider
> audience and see if we can't garner more interest and participation.  As
> a result, I am proposing the creation of a new OpenSolaris Project to
> address the ease and automation of printing related configuration
> management.  Below is a brief description of what we are looking to
> address.  Obviously, this is open to change based on input and
> participation, but It's a place to start.
>

[Off Topic]:
I realize that I'm not an expert in printing but why don't we "just" use CUPS? 
It seems to have all these features already. Plus there are handful of GUIs 
for it and seems to be pretty much a standard in linux/mac world.

Cheers,
spity

PS: OK, I understand compatibility restraints, but except of those...
-- 
Jan Spitalnik
[EMAIL PROTECTED]
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] How to find the number of cores on T1 processor

[Bart Smaalders]

Nikolay Piskun wrote:

I think this is more general for all processors, but I am mostly interested in 
T1 which is 8 core 32 virtual processors. The question is, is there any 
function call, that returns the number of cores instead of the number of 
virtual processors.
Thanks,
 


Why do you care?  How will your code cope with more sophisticated
processors a year from now?

- Bart


--
Bart Smaalders  Solaris Kernel Performance
[EMAIL PROTECTED]   http://blogs.sun.com/barts
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] Re: Re: How to find the number of cores on T1 processor

[Nikolay Piskun]

Thank you very much, it works. 
Nikolay
www.etnus.com
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Re: Shipping "lsof" with Solaris ? / was: Re: problem with /t

[James Carlson]

Dave Marquardt writes:
> a> Just having to compile `lsof` every time the kernel rev changes is already
> a> too much overhead. At any given day, there are many issues, feature
> a> requests and fixes to the build, that it is really inefficient to have one
> a> more thing to worry about -- some crappy utility written by an external 3rd
> a> party whose only benefit is to show open ports and files.
> 
> It occurred to me that we might be able to leverage the CTF
> information that mdb uses to decode structures in the kernel.
> Unfortunately, last I looked, the CTF lookup code in mdb was not a
> public interface, so I'm not sure we can go there at this point.  But
> if we could, then we could use CTF to look up the structure definition
> and avoid recompiling lsof (or some similar program).

That only solves part of the problem (the binary offset issues).  A
bigger problem is that the structures and the structure members
themselves are not stable between patches or builds -- they're not
stable interfaces in the first place.  This means that if someone
renames "foo" to "bar," CTF isn't going to be able to tell you what
happened to "foo."

-- 
James Carlson, Solaris Networking  <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Project Proposal: PRESTO - Automatic Printing Configuration

[Bart Smaalders]

Norm Jacobs wrote:



  Purpose

To improve Solaris approachability, specifically the print service, by
automatically (or as automatically as possible) discovering and
configuring access to directly attached, network attached, and remotely
served printers.



+1

If we can automatically discover broadcasting MAC and Windows network
hosted printers and make them useable, and automatically/easily
setup print queues  and advertise them to Macs and Windows clients,
it would truly be a huge step forward.

- Bart


Bart Smaalders  Solaris Kernel Performance
[EMAIL PROTECTED]   http://blogs.sun.com/barts
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Re: Shipping "lsof" with Solaris ? / was: Re: problem with /t

[Casper . Dik]

>It occurred to me that we might be able to leverage the CTF
>information that mdb uses to decode structures in the kernel.
>Unfortunately, last I looked, the CTF lookup code in mdb was not a
>public interface, so I'm not sure we can go there at this point.  But
>if we could, then we could use CTF to look up the structure definition
>and avoid recompiling lsof (or some similar program).

For some things, such as computing offsets in structures, CTF
data is a possible source.

For other things, such as complete rewrites of how the kernel works in
certain areas, of which we see several each OS release, it would not
work.

Casper
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Re: Shipping "lsof" with Solaris ? / was: Re: problem with /t

[Dave Marquardt]

"James" == James Carlson <[EMAIL PROTECTED]> writes:

>> It occurred to me that we might be able to leverage the CTF
>> information that mdb uses to decode structures in the kernel.
>> Unfortunately, last I looked, the CTF lookup code in mdb was not a
>> public interface, so I'm not sure we can go there at this point.  But
>> if we could, then we could use CTF to look up the structure definition
>> and avoid recompiling lsof (or some similar program).

James> That only solves part of the problem (the binary offset issues).  A
James> bigger problem is that the structures and the structure members
James> themselves are not stable between patches or builds -- they're not
James> stable interfaces in the first place.  This means that if someone
James> renames "foo" to "bar," CTF isn't going to be able to tell you what
James> happened to "foo."

Agreed.
-- 
Dave Marquardt
Sun Microsystems, Inc.
Austin, TX
+1 512 401-1077 (SUN internal: x64077)
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] Re: .profile not executing

[Brian Leonard]

I knew it was something dumb like that - thanks. I'm still not sure why 
.profile was executed when doing a "su - bleonard" though.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [install-discuss] Re: [osol-discuss] rpm vs pkgadd (again!)

[Dave Miner]

James Carlson wrote:

Laszlo (Laca) Peter writes:

On Mon, 2007-01-08 at 13:57 -0500, James Carlson wrote:

The existing rule is that you need to build on a system that is at
least as old as what you plan to support.  You can then test for that
minimum system version and (because libraries are carefully designed
to be stable ;-}) run on any newer version.

Exactly.  But how do I express this as a package dependency?
In other words, what stops users from installing my package
on a system that is older than the oldest I plan to support?


If you avoid microscopic package versioning, you either tell customers
"supported on Solaris X and above" and be done with it, or (if you're
feeling pedantic) you test uname -r and the existence of the objects
(such as /usr/lib/libfoo.so.1) in question during a preinstall script.



Actually, that should be in a checkinstall script.


For things on existing versions of Solaris, delivery of patches gives
you a richer way to express dependency, because of just this problem.
It's not well connected with packaging, though.



Overall, though, I don't think integrating generic >= pseudo-numeric 
version checks in the packaging system is all that attractive; few of 
the versioning systems used by the different families of packages seem 
to behave consistently, either within themselves or across families, 
thus it seems a waste to invest there when it's only effective if 
discipline is observed by the package maintainers.


Dave
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

[osol-discuss] Why Solaris 10 update3 boots directly into the console mode login?

[MichaelLi]

I just have freshly installed Solaris 10 update3. The install process goes well 
without any problem. But  after the system reboots, it directly boots into the 
console mode login, not the graphic login mode as the previous release does. So 
how could I fix this? Why it behaved like this? 

Thanks in advance.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

RE: [osol-discuss] Debug the Dynamic Linker

[Deepak Bhatia]

Hi Rod,

Thanks a lot for the reply and it is very useful.

mdb document seems to be very large. Do we have a quick user guide for the same.

Regards

Deepak Bhatia

-Original Message-
From: Rod Evans [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 09, 2007 4:27 AM
To: DEEPAK BHATIA
Cc: opensolaris-discuss@opensolaris.org
Subject: Re: [osol-discuss] Debug the Dynamic Linker


DEEPAK BHATIA wrote:

> Can anyone please suggest how to proceed ? How do I tell the OS to invoke my 
> dynamic linker instead of the original one.

You can explicitly invoke a different runtime linker:

oxpoly 428. cp /usr/lib/ld.so.1 /tmp/ld.so.1
oxpoly 429. /tmp/ld.so.1 /bin/cat &
[1] 17398
oxpoly 430. pmap 17398
17398:  /tmp/ld.so.1 /bin/cat
0001  16K r-x--  /usr/bin/cat
00024000   8K rwx--  /usr/bin/cat

FF3B 208K r-x--  /tmp/ld.so.1
FF3F4000   8K rwx--  /tmp/ld.so.1

You can also embed the name of a non-default runtime linker
within an application:

oxpoly 435. LD_OPTIONS=-I/tmp/ld.so.1 cc -o main  main.c
oxpoly 436. elfdump -i main

Interpreter Section:  .interp
 /tmp/ld.so.1

I use mdb(1) to debug ld.so.1, plus there are some helper functions
available from our mdb module.  See

   http://docs.sun.com/app/docs/doc/817-1984/6mhm7pl1k?a=view

And, don't forget printf's :-)  They are easy to add, and it takes
just seconds to rebuild ld.so.1.

-- 
Rod


___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org