nd charset-unspecified text was scrubbed...
Name: spec.txt
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080312/488f5275/attachment.txt>
Joseph Kowalski wrote:
> Are you just saying "I don't want to do this, but if Ken (the actual
> project owner) is willing, they
> I (Joerg) has no objection"?
>
> Just making sure we are communicating...
For me these interfaces are publically usable. This is why I don't remove the
documentatio
Alan Coopersmith wrote:
> How would an external person get the information to create the docs - reverse
> engineer the source code? Is there no internal specification other than the
> source code for them? I believe that's the docs Joerg is asking for - not a
> man page suitable for end users
Nicolas Williams wrote:
> On Wed, Mar 12, 2008 at 08:09:24AM -1000, Joseph Kowalski wrote:
>
>>> Correct. We agree those go in /usr/lib.
>>>
>>>
>> Well maybe. Certainly not /usr/bin, but perhaps we are starting to
>> add too much to the clutter. Sorta like sweeping the crumbs from
Shawn Walker wrote:
> Adding SMF, etc. does not affect the portability here if done properly.
>
+1
Although a certain amount of slack can be given in this case, the final
point should
be to use SMF, etc.
The Solaris environment is not the Linux environment (assuming there is
a single
Linux e
Darren J Moffat wrote:
> How is it different to pilot-xfer or gphoto or any of the other
> libusb consumers ?
>
> I just don't see what the issue is with this case. If there is an
> object reuse issue then the issue is with logindevperm giving out
> access to all the ugen provided devices as a
Darren J Moffat wrote:
> I'd personally see it that the policy wasn't relevant to this case but
> would be relevant to a future case that builds on this to have star
> replace /usr/bin/tar.
+1
sed -e "s/relevant to/waived for/g"
- jek3
Gee, my first chance to disagree with Glenn. I feel special! :-)
(With all the language problems, I hope that somebody from NJ (NY?) can see
that this is a complement!)
Glenn Fowler wrote:
> just as ksh93 provides a user builtin/plugin api for extending ksh93
> I would recommend a plugin api f
Margot Miller wrote:
>
> When integrating a project through SFW consolidation, is it requirement
> that it be modified to fit into SMF?
>
> Thanks,
> Margot
IMHO, the sfw consolidation is just to allow a relaxation of some rules
of ON.
Makefile syntax and "no warnings" come to mind. SFM is as a S
Bill Sommerfeld wrote:
> On Wed, 2008-03-12 at 10:00 -0800, Gary Winiger wrote:
>>> I don't understand why a scanner would be classed as removable media.
>> Because you put removable stuff in it and remove the stuff when
>> done. Solaris Object Reuse needs to be supported.
>
> I'm still
ndency.
>
OK. I'll do that.
Thanks,
Lei Chen
> Gary..
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080312/147aef16/attachment.html>
> I suppose you could argue that the project teams that integrate
> devices needing object reuse into Solaris are not responsible.
> Please convince your (and my) director that the responsibility
> lies somewhere else.
Gary,
There are two possibilities here, neither of whi
Gary Winiger wrote:
> > These are older implementaions. If you use rmt from star without
> > /etc/default/rmt, you get more security than the current rmt implements.
> > This may cause people to fail with their access patterns. If you like to
> > make rmt as permissive as historical implementai
> Please be explicit.
The device allocation subsystem is in control. The user
only has access to the specific device by allocating it,
see allocate(1). The user runs along happily scanning.
The user is done and deallocates it, see deallocate(1).
The deallo
Casper.Dik at Sun.COM wrote:
> >librmt from star has a fallback to the slow "rsh somehost /etc/rmt".
> >If it is called by root or installed suid root, it will call rcmd(3)
> >to avoid the pipe.
>
> What about privileges? IMHO, it should just try rcmd(3) and see whether
> that fails with a "sock
> 2) There is an object reuse issue with the inclusion of ugen devices in
> our default logindevperm by PSARC 2005/187 ("libusb should just work");
IIRC, when device allocation is configured logindevperm is
largely zapped.
The point is when operating within device allocati
John Plocher wrote:
> You are not listening. Or I am not hearing.
>
> What do you mean by "information remaining in the device"?
>
> Please be explicit.
>
> Even after deallocating and reallocating then,
> o An audio input device still passes on sounds made in its
> vicinity,
> o A web
"Garrett D'Amore" wrote:
> > Star is an integrated source for all three CLI interfaces and more.
> > Star could replace the current binaries in future, but then I/we need to
> > implement support for private extensions in the current OpenSolaris code.
> >
>
> As far as I'm concerned, if we can
>Andrew Gabriel wrote:
>
>> Gary Winiger wrote:
>> >I don't know and never have see a justification for any
>> >executables in /etc/* IMO, doing so needs some extra special
>> >justification that I don't see in the spec.
>>
>> I believe the rmt protocol is defined to be invoked as
>>
Gary Winiger wrote:
> > > Proposal:
> > >
> > > Integrate schily tar (star), a tar-like clone with more
> > > features
> >
> > Does star(1) support the Trusted Solaris extensions?
>
> I should have asked: "Does star(1) support all the functionality
> of tar(1
>Casper.Dik at sun.com wrote:
>
>>
>> One not unimportant question: does librmt support anything other than
>> rshd? sshd would be nice.
>
>Simply use:
>
>RSH=/usr/bin/ssh .
Hm, OK. I think we're doing an as-is open source integration so I guess
that is fine. A ~/.librmtrc would be nice
Margot Miller wrote:
>
> When integrating a project through SFW consolidation, is it requirement
> that it be modified to fit into SMF?
Consolidation isn't the issue. It is wither or not the intention is to
integrate unmodified upstream source or provide a fully integrated part
of Solaris.
I'
Gary Winiger wrote:
>> Gary Winiger wrote:
> Note that Sane and libsane was previously ARC'ed via LSARC
>
> http://sac.eng.sun.com/arc/LSARC/2007/018/
>>> Just what is the relationship between this case and the sited
>>> LSARC case? Why is the LSARC case listed as a referenc
Andrew Gabriel wrote:
> Gary Winiger wrote:
> > I don't know and never have see a justification for any
> > executables in /etc/* IMO, doing so needs some extra special
> > justification that I don't see in the spec.
>
> I believe the rmt protocol is defined to be invoked as
> "rsh s
...and the pathname of the real rmt executable (whether in /usr/sbin or
/usr/lib) could be uncommitted, as it's accessed via /etc/rmt.
Margot Miller wrote:
> Rereading the original case PSARC/2004/480, this issue came up before.
>
> > It should probably have never been in /usr/sbin anyway, but
>
Thanks :(
I thought I've updated it.
--Irene
On Tue, 2008-03-11 at 10:09 -0700, John Fischer wrote:
> Irene,
>
> I have updated the IAM file for you to be 'closed approved'.
>
> Thanks,
>
> John
Gary Winiger wrote:
> > Current changes:
> >
> > - /usr/sbin/rmt executable from ON replaced by the rmt from star
> > - /etc/default/rmt configuration file added (defaults to full
> > access)
>
> In the face of the SMF policy,
> http://opensolaris.org/os/community
Casper.Dik at sun.com wrote:
>
> One not unimportant question: does librmt support anything other than
> rshd? sshd would be nice.
Simply use:
RSH=/usr/bin/ssh .
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de
You are not listening. Or I am not hearing.
What do you mean by "information remaining in the device"?
Please be explicit.
Even after deallocating and reallocating then,
o An audio input device still passes on sounds made in its
vicinity,
o A web camera still shows the images of what
One not unimportant question: does librmt support anything other than
rshd? sshd would be nice.
Casper
> > The same as we do /dev/audio. We reset any state that can be
>
>
> OK, maybe I'm dense, but what is the perceived failure mode here?
> Is it "someone left a page on the scanner" or is it something else?
It's that there is information remaining in the device that
can be a
>Casper.Dik at Sun.COM wrote:
>> For Solaris we generally do not use auto configuration; this includes even
>> things like perl.
>
>s/Solaris/ON/ - there's a lot of autoconfiguration in the rest of Solaris -
>X, JDS, SFW - probably more software is autoconfigured there than delivered
>by all of ON
"Garrett D'Amore" wrote:
> Hang on... that /etc/rmt symbolic link *already* exists. I don't think
> we need to do anything here -- its already there:
/etc/rmt is part of the rmt protocol as established in 1981 on BSD.
If you remove it, you need to call star:
RMT=/path/to/server star
if
On Wed, 2008-03-12 at 10:00 -0800, Gary Winiger wrote:
> > I don't understand why a scanner would be classed as removable media.
>
> Because you put removable stuff in it and remove the stuff when
> done. Solaris Object Reuse needs to be supported.
I'm still not understanding why yo
Gary Winiger wrote:
>> What's more, the software being proposed here does not need special
>> privileges to operate; if some sort of device allocation/object reuse
>> controls need to happen, they would need to happen in trusted privileged
>> code at device open time.
>
> If the device alloc
Joerg Schilling wrote:
> Gary Winiger wrote:
>
>
Proposal:
Integrate schily tar (star), a tar-like clone with more
features
>>>
>>> Does star(1) support the Trusted Solaris extensions?
>>>
>> I should have asked: "Does star(
Joseph Kowalski wrote:
> OK, let's take this by steps.
>
> Do you agree to remove *all* references to the internal libraries
> provided by this case
> from all man pages?
For me, these libs are not internal only. If someone at Sun likes to edit the
man pages to remove the references as long as
Joseph Kowalski wrote:
> 3. "used by several programs on OpenSolaris" is not the same as "used by
> several
> programs *provided by* OpenSolaris".
If you introduce a neew nomenclature, please explain the meaning.
OpenSolaris does not even boot without mkisofs.
J?rg
--
EMail:joerg at sc
Gary Winiger wrote:
>> I wonder how we do "object reuse" scrubbing for a webcam ? Ask the user
>> to put a cloth over the camera ;-)
>
> The same as we do /dev/audio. We reset any state that can be
OK, maybe I'm dense, but what is the perceived failure mode here?
Is it "someone left a p
Joseph Kowalski wrote:
> Joerg Schilling wrote:
>> Joseph Kowalski wrote:
>>
>>
>>> OK, let's take this by steps.
>>>
>>> Do you agree to remove *all* references to the internal libraries
>>> provided by this case
>>> from all man pages?
>>>
>>
>> For me, these libs are not internal only.
> I wonder how we do "object reuse" scrubbing for a webcam ? Ask the user
> to put a cloth over the camera ;-)
The same as we do /dev/audio. We reset any state that can be
read out to some default state. We also control which user
is authorized access to /dev/audio.
Ga
> On Wed, 2008-03-12 at 10:00 -0800, Gary Winiger wrote:
> > > I don't understand why a scanner would be classed as removable media.
> >
> > Because you put removable stuff in it and remove the stuff when
> > done. Solaris Object Reuse needs to be supported.
>
> I'm still not understandi
"Garrett D'Amore" wrote:
> > What do you understand by pax(1)?
> >
> > The pax binary in /usr/bin on Solaris is closed source and it makes no
> > sense to
> > even think about enhancing it.
> >
>
> That doesn't preclude integrating an alternate implementation, though.
> (And this may be de
> How would an external person get the information to create the docs - reverse
> engineer the source code? Is there no internal specification other than the
> source code for them? I believe that's the docs Joerg is asking for - not a
> man page suitable for end users.
No internal doc
On Wed, Mar 12, 2008 at 1:26 PM, Margot Miller wrote:
> In trying to keep to a minimal amount of change from the source, we would
> like to not have to implement SMF for this project.
>
> In talking to Joerg, it seems that the configuration and syntax of these
> star
> configuration files is w
Joerg Schilling wrote:
> "Garrett D'Amore" wrote:
>
>
>>> Star is an integrated source for all three CLI interfaces and more.
>>> Star could replace the current binaries in future, but then I/we need to
>>> implement support for private extensions in the current OpenSolaris code.
>>>
>>>
non-controversial
>>> or appropriate for FastTrack. At any rate, effort should be made
>>>
>> For LSARC/2007/018, I don't think it's derailed. From the case's log, I
>> read the following,
>>
>
> I don't believe the LSARC case was derailed. It went into
> waiting need spec. From which it hasn't progressed. Thus
> my question of the relationship.
>
> Gary..
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080312/9928c492/attachment.html>
I agree, *-config shouldn't have to belong to /usr/bin. That they do is
an accident of history that we probably cannot really change now.
On Wed, Mar 12, 2008 at 08:09:24AM -1000, Joseph Kowalski wrote:
> > Correct. We agree those go in /usr/lib.
> >
> Well maybe. Certainly not /usr/bin, but perhaps we are starting to
> add too much to the clutter. Sorta like sweeping the crumbs from one
> room to another.
>
> BTW: The number
Margot Miller writes:
>
> When integrating a project through SFW consolidation, is it requirement
> that it be modified to fit into SMF?
SMF is a Solaris / OpenSolaris issue, not a per-consolidation policy.
However, SFW _does_ have a policy of minimal changes from the
upstream.
You'll probably
On Wed, 12 Mar 2008 18:00:27 +0100 Joerg.Schilling at fokus.fraunhofer.de
(Joerg Schilling) wrote:
> "Garrett D'Amore" wrote:
> > > Star is an integrated source for all three CLI interfaces and more.
> > > Star could replace the current binaries in future, but then I/we need to
> > > implement
Gary Winiger wrote:
>> Gary Winiger wrote:
The problem with the trusted Solaris extensions is that they are
undocumented.
>>> Add a service request to
>>> 6575215 archives.3head: tar/ustar extended headers information for
>>> TX not documented
>>> and escalate it.
>> For
On Wed, Mar 12, 2008 at 12:11 PM, Joerg Schilling
wrote:
> Gary Winiger wrote:
>
>
> > > These are older implementaions. If you use rmt from star without
> > > /etc/default/rmt, you get more security than the current rmt implements.
> > > This may cause people to fail with their access patterns
James Carlson wrote:
> Glenn Fowler writes:
> > i.e., they allow users to build their own libfoo.so for
> > builtin -f foo [ foo_builtin_1 ... foo_builtin_N ]
> > the ast libcmd.so is one example of a user runtime builtin/plugin
>
> Ah, ok, I'd forgotten about that. That makes sense.
>
> I d
> Gary Winiger wrote:
> >> The problem with the trusted Solaris extensions is that they are
> >> undocumented.
> >
> > Add a service request to
> > 6575215 archives.3head: tar/ustar extended headers information for
> > TX not documented
> > and escalate it.
>
> For an OpenSolaris
> When integrating a project through SFW consolidation, is it requirement
> that it be modified to fit into SMF?
Are there separate Solaris/SAC Architectural policies based on
Consolidation?
I don't believe so. There may be different business policies
based on inte
>Nicolas Williams wrote:
>
>> On Tue, Mar 11, 2008 at 03:24:13PM +0100, Joerg Schilling wrote:
>
>> > The problem with crosss compilations is that it does not really work if
>> > the
>> > software uses dynamic autoconfiguration for portability.
>>
>> That doesn't make cross-compilation useless.
"Garrett D'Amore" wrote:
> Most of ON is not autoconfigured. The only exceptions I can think of
> would likely be related to 3rd party software (perl?)
>
> Certainly NetBSD has found solutions to this problem. :-)
>
> I wouldn't mind putting some of the 3rd party software that depends on
> suc
Glenn Fowler wrote:
>
> On Tue, 11 Mar 2008 09:41:28 -0400 James Carlson wrote:
> > Darren J Moffat writes:
> > > We do have /usr/include/ast though.
>
> > Unless it's really reasonable and expected for third parties to link
> > against libast, I think that's very likely to be a mistake. We shou
Gary Winiger wrote:
>>> Note that Sane and libsane was previously ARC'ed via LSARC
>>>
>>> http://sac.eng.sun.com/arc/LSARC/2007/018/
>
> Just what is the relationship between this case and the sited
> LSARC case? Why is the LSARC case listed as a reference?
The LSARC case propose
In trying to keep to a minimal amount of change from the source, we would
like to not have to implement SMF for this project.
In talking to Joerg, it seems that the configuration and syntax of these
star
configuration files is well-known for administrators across a wide set of
operating systems-
Nicolas Williams wrote:
> On Tue, Mar 11, 2008 at 03:24:13PM +0100, Joerg Schilling wrote:
> > The problem with crosss compilations is that it does not really work if the
> > software uses dynamic autoconfiguration for portability.
>
> That doesn't make cross-compilation useless.
I don't like
Asif Naeem writes:
> Hi, there are some compilation issues with pgbouncer on solaris 9 e.g. struct
> msghdr.msg_controllen is missing on solaris 9. can u please guide me.Thanks.
You need to compile in a standards-compliant (not compatibility)
environment. See libxnet(3LIB) and standards(5).
The
Gary Winiger wrote:
>> The problem with the trusted Solaris extensions is that they are
>> undocumented.
>
> Add a service request to
> 6575215 archives.3head: tar/ustar extended headers information for
> TX not documented
> and escalate it.
For an OpenSolaris community m
"Garrett D'Amore" wrote:
> Joerg Schilling wrote:
> >
> >
> > If people ask questions that are answered in the man pages, it is obvious
> > to
> > point to the related man pages. If the issues beyond integrating star at all
> > are not forgotten again, I can live with a phased integration.
> >
>
SANE does not depend on HAL for device access control.
>>> Why shouldn't it? Isn't it removable media?
>>>
>> I don't understand why a scanner would be classed as removable media.
>>
>
> Because you put removable stuff in it and remove the stuff w
"Garrett D'Amore" wrote:
> Please stop trying to draw parallels there. The ast stuff was *I
> believe* reviewed. The ARC and CTeams are free to review cases on
> their own merit, with little regard to what other "unrelated" project
> may have done.
>
> You cannot hold OpenSolaris hostage Jo
This case was approved during ARC business today.
liane
>Repeat after me
>
>ast may or may not be appropriate. If it isn't, we blew it, but the
>ARCs don't allow "double
>jeprody"[1]. The existence of ast in Solaris is unrelated to star
>(and associated).
>
>- jek3
>
>[1] I don't know if Germany has the concept of "double jeprody".
> Gary Winiger wrote:
> >>> Note that Sane and libsane was previously ARC'ed via LSARC
> >>>
> >>> http://sac.eng.sun.com/arc/LSARC/2007/018/
> >
> > Just what is the relationship between this case and the sited
> > LSARC case? Why is the LSARC case listed as a reference?
>
> The LSAR
> Gary Winiger wrote:
>
> > > Current changes:
> > >
> > > - /usr/sbin/rmt executable from ON replaced by the rmt from star
> > > - /etc/default/rmt configuration file added (defaults to full
> > > access)
> >
> > In the face of the SMF policy,
> > http://opensolari
Joerg Schilling wrote:
> Joseph Kowalski wrote:
>
>
>> OK, let's take this by steps.
>>
>> Do you agree to remove *all* references to the internal libraries
>> provided by this case
>> from all man pages?
>>
>
> For me, these libs are not internal only. If someone at Sun likes to edit the
When integrating a project through SFW consolidation, is it requirement
that it be modified to fit into SMF?
Thanks,
Margot
Gary Winiger wrote:
>> Gary Winiger wrote:
>>
>>
Current changes:
- /usr/sbin/rmt executable from ON replaced by the rmt from star
>>>
> The problem with the trusted Solaris extensions is that they are undocumented.
Add a service request to
6575215 archives.3head: tar/ustar extended headers information for
TX not documented
and escalate it.
This case raised the following issues:
o integrating unzoo in isolation is architecturally
incomplete without the corresponding zoo command
which in itself allows for the extraction of files
from zoo archives.
o the little utility for having such a command.
o the command should be an O
Will add /etc/default/star to the interface table.
Margot
>
>
>
>> Similarly the star(1) man page in the materials directory
>> appears to have an /etc/default/star file specified.
>> I guess that isn't delivered as it's not listed in the
>> interfaces.
>>
>
> star'
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080312/8e6b226f/attachment.html>
Joerg Schilling wrote:
> Joseph Kowalski wrote:
>
>
>> OK, let's take this by steps.
>>
>> Do you agree to remove *all* references to the internal libraries
>> provided by this case
>> from all man pages?
>>
>
> For me, these libs are not internal only. If someone at Sun likes to edit the
Rereading the original case PSARC/2004/480, this issue came up before.
> It should probably have never been in /usr/sbin anyway, but
> rather somewhere in /usr/lib. I believe it is always invoked
> as /etc/rmt, which could presumably point somewhere else if the
> need arose and it was thought
Joerg Schilling wrote:
> Joseph Kowalski wrote:
>
>
>> OK, let's take this by steps.
>>
>> Do you agree to remove *all* references to the internal libraries
>> provided by this case
>> from all man pages?
>>
>
> For me, these libs are not internal only. If someone at Sun likes to edit the
> and the 64-bit delivery dependency. If absolute sequencing is required,
> the project
> team can deliver the CR fix first before the libsane/sane delivery.
Those a P/C team issues the architectural issue is to deliver for
all ISAs.
Gary..
Garrett D'Amore wrote:
> Can't say that I'm thrilled that we seem so willing to abdicate our
> engineering decisions to FOSS groups who have repeatedly shown (at
> least IMO) that they often have little regard for sound architecture,
> and even less regard for portability to Solaris or stable in
Casper.Dik at Sun.COM wrote:
> One not unimportant question: does librmt support anything other than
> rshd? sshd would be nice.
>
> Casper
>
>
Joerg already indicated to me at least, that it does support ssh. This
is one of the reported advantages to linking directly against librmt.
--
Nicolas Williams wrote:
>> (Now, "helper" applications, such as a program that is really only a
>> helper for another GUI application, are a different matter entirely.
>> /usr/bin/totem-video-indexer is a good example. I suspect that it
>> serves no useful purpose living in /usr/bin.)
>>
Joerg Schilling wrote:
> "Garrett D'Amore" wrote:
>
>
>> Hang on... that /etc/rmt symbolic link *already* exists. I don't think
>> we need to do anything here -- its already there:
>>
>
> /etc/rmt is part of the rmt protocol as established in 1981 on BSD.
> If you remove it, you need to
Alan Coopersmith wrote:
> Garrett D'Amore wrote:
>> Looking at *-config, I was bemoaning the fact that these FOSS
>> packages feel the need to drop their detritus in my path. There are
>> far far better solutions that could have been done had some actual
>> "engineering" taken place. (E.g. a c
Casper.Dik at Sun.COM wrote:
> For Solaris we generally do not use auto configuration; this includes even
> things like perl.
s/Solaris/ON/ - there's a lot of autoconfiguration in the rest of Solaris -
X, JDS, SFW - probably more software is autoconfigured there than delivered
by all of ON.
--
Hi, there are some compilation issues with pgbouncer on solaris 9 e.g. struct
msghdr.msg_controllen is missing on solaris 9. can u please guide me.Thanks.
This message posted from opensolaris.org
Garrett D'Amore wrote:
> Looking at *-config, I was bemoaning the fact that these FOSS packages
> feel the need to drop their detritus in my path. There are far far
> better solutions that could have been done had some actual "engineering"
> taken place. (E.g. a common registry, or dot files i
> > Proposal:
> >
> > Integrate schily tar (star), a tar-like clone with more
> > features
>
> Does star(1) support the Trusted Solaris extensions?
I should have asked: "Does star(1) support all the functionality
of tar(1)? If not what's missing?"
Ga
> Glenn Fowler wrote:
>
> >
> > On Tue, 11 Mar 2008 09:41:28 -0400 James Carlson
> wrote:
> > > Darren J Moffat writes:
> > > > We do have /usr/include/ast though.
> >
> > > Unless it's really reasonable and expected for
> third parties to link
> > > against libast, I think that's very likely to
Gary Winiger wrote:
> I don't know and never have see a justification for any
> executables in /etc/* IMO, doing so needs some extra special
> justification that I don't see in the spec.
I believe the rmt protocol is defined to be invoked as
"rsh somehost /etc/rmt" under the cov
"Garrett D'Amore" wrote:
> If star and rmt logically belong in ON, then that is where they should
> go. Note that I believe that the "bar" for entry into ON is probably a
> bit higher, though. (Your sources should be cstyle and lint clean, your
> Makefiles have to follow ON convention, etc.)
93 matches
Mail list logo
