star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Garrett D'Amore gdamore at sun.com 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.) my sources all pass a cstyle -l132 -b -K -B check and do not give compiler warnings. I don't know what lint checks are run on ON. This seems however not be done for all current ON programs as I am still not done with cleaning up the Bourne shell sources and I did spend a lot of time to make SCCS compiler warning clean. The makefile system used for star is portable. Creating a non-portable set of makefiles for Solaris would be a special effort. Creating a non-portable variant of the include files is not worth the effort. There is another option, which is to establish a contract, which could allow the use of a separate copy of the headers. I'm not a big fan of this option, but it is possible. I am not sure whether I understand you correctly. Could you explain what you understand by contract? Just out of curiosity, what is the main benefit to ufsdump/ufsrestore gained by linking directly to librmt? - librmt supports to use ssh for the connection This is a demand from major customers - librmt supports to use ssh for the connection This is a demand from major customers - librmt allows ufsdump/ufsrestore to connect to GNU rmt - rmt from star is faster than the current Solaris rmt - rmt from star gives better abstraction from OS/platform specific data structures - rmt from star allows to configure which files are accessible by whom J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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 covers, so /etc/rmt is part of the rmt protocol. Given that rmt is never invoked directly as a command as far as I'm aware, it's not clear to me that /usr/sbin/rmt is the right location for the real binary. Somewhere in /usr/lib/ might be more appropriate. -- Andrew Gabriel
Nethack 3.4.3 [PSARC/2008/172 FastTrack timeout 03/11/2008]
On Mon, Mar 10, 2008 at 02:06:55PM -0500, Shawn Walker wrote: I think a better way to handle it is as you suggested: only put things intended for humans to type in /usr/bin (and thus, the PATH). Well, I do think that scripts need to be careful to set PATH correctly, but still, Garret's autoconf/configure and *-config example is very instructive, even if in the opposite way that he intended. But then, script writing shouldn't be made unnecessarily harder. Nico --
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
-- An HTML attachment was scrubbed... URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080312/9928c492/attachment.html
Nethack 3.4.3 [PSARC/2008/172 FastTrack timeout 03/11/2008]
Nicolas Williams wrote: On Mon, Mar 10, 2008 at 02:06:55PM -0500, Shawn Walker wrote: I think a better way to handle it is as you suggested: only put things intended for humans to type in /usr/bin (and thus, the PATH). Well, I do think that scripts need to be careful to set PATH correctly, but still, Garret's autoconf/configure and *-config example is very instructive, even if in the opposite way that he intended. But then, script writing shouldn't be made unnecessarily harder. Nico Ugh. I just can't seem to resist replying. Sorry in advance 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 in ~, or something.) Heck even manually searching the items in PATH with an append of ../lib/pkg-config or somesuch. However, I also understand that we can't change the world. Unfortunately, it appears that in the current regime, when Linux or GPL delivers stuff that is basically crap (don't even get me started on autoconf/automake!), the expectation is that we will ship the same crap, in more or less the same locations, all to serve the new higher god of serendipitous discovery (or Linux compatibility.) 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 interfaces. Oh well hopefully its helping to win hearts and minds somewhere, or something like that. -- Garrett /me longs for the day when Linux was trying to be more like Solaris -- early FSSTND -- that's the precursor to FHS -- were inspired greatly by Solaris and SunOS, rather than the reverse.
Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008]
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
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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. It is that once you have been acquitted by a court of an infraction, you can't be tried again. (The ARC modifies this in that one can alter a decision based on significant new information and agreement of the CTO (or equivalent). Its happened only a few times. I think you may mean double jeopardy although you spelled it consistently. The equivalent in some European countries would be ne bis in idem (Latin loosely meaning not twice for the same) Casper
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Garrett D'Amore gdamore at sun.com 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 Joerg, sorry. A real strange statement If we have no general rules for OpenSolaris, we will end in a chaos soon. I hope we are not in the animal farm: All animals are equal but some animals are more equal than others. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
unzoo integration [PSARC/2008/183 FastTrack timeout 03/14/2008]
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 Obsolete command as opposed to Committed (if it were to be integrated). o rather than doing unzoo in isolation the pax command could be enhanced to deal with the extra archive formats. o file-roller(1) expects to use zoo (and the associated command line) as opposed to unzoo to extract zoo archives. As such the project team have decided to withdraw this case. Thanks pete
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Garrett D'Amore gdamore at sun.com 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. 1) If there are more detailed man pages here, then they are absent from the case materials. I shouldn't have to googling around to find out materials that are intrinsic to the case. I don't know what's in the case material. The star project is documented. If you like to discuss documentation, fetch the related documentation first. Recent star documentation is in the star source tree ftp://ftp.berlios.de/pub/star/alpha/ From time to time, there is a update in the web man pages at: http://cdrecord.berlios.de/private/man/star/ BTW: the function you have been asking for is a function that only exists to the benefit of ufsdump and it seems to be intentionally undocumented by Sun, it is however documented in the man pages that come with librmt. See e.g. http://cdrecord.berlios.de/private/man/star/rmtinit.3.html 2) The above paragraph conveys a message that you expect someone (PSARC?) to drive forward with making libshily (or whatever it is called) public. If you want to do that, then *you* (or some project team you might be working with) needs to do that. PSARC doesn't normally start new cases on its own -- a project team has to start the process. You can't hold the ARC hostage to your future demands, and you can't expect it to do work that you should be taking on yourself. PSARC 2004/480 already coveres most of the changes. I believe we only need to refresh things. 3) I'm a bit unhappy with the term phased integration. While the integration may be phased, what I'm most concerned with is the review process. phased review might be a better term. More simply, I don't think we are talking about this case offering any review (and thus no opinion nor precedent) as to the integration (or lack thereof) of this portability layer. The problem with the current rules (avoid to put new code into ON) is that it requires a phased integration. If you like to compile code that depends on other code that is not located in the same consolidation, you first need to make the dependencies available. BTW: I would prefer to see a self contained ON source. 3) That said, are we in agreement that this case is just about star and rmt for now, and that if you want to do /usr/include/schily (or whatever) you will need to come back to ARC with a case for that? See above, if you like to let ufsdump use librmt, then the current rules require two additional PSARC cases and code integration phases: 1) Add /usr/include/schily/ and /usr/lib/librmt.so to SXCE to allow future compilation of ON with enhanced code. 2) Enhance the code in ON to let ufsdump/ufsrestore/mt use the new interfaces. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
PSARC/2008/179 cross link-editor
Nicolas Williams Nicolas.Williams at sun.com 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 to say this, but it makes cross compilation harder than people may expect. Many people believe that cross compilation is easy because the GNU autoconf documentation incorrectly claims this is something that works by default. In fact, GNU autoconf provides some basic fallback definitions that apply for Linux and that may allow to compile a piece of software on a different Linux platform. If you like or need to go beyond this, you start hand crafting the autoconf results. You would first need to hand craft _all_ autoconfiguration results for the target platform. Not in the ON consolidation, for example, but yes in SFW (which really means that SFW might well never cross-build). This is no longer true for ON since ON contains ksh93 and if more software that uses dynamic configuration is added to ON, things become even harder. Note that you cannot create a non-portable (static) variants from ksh93, star, cdrtools, ... for Solaris because nobody would pay for this unneeded fork. In order to avoid confusion: ksh93 creates static include files for the ISAs that are already supported in native compile mode. New platforms need new include files. This case will help third parties who want to cross-build using GCC but cross-link with the Solaris linker. So there are worthy use cases, even though they won't generalize to all developers. If we can also leverage this in any OpenSolaris consolidations, all the better, and if not, oh well. It is worth to do (in special as the GNU ld also does it) but the pitfalls should be documented. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
Gary Winiger wrote: Then again, a quick examination of /usr/lib and /usr/sfw/lib turns up hundreds of libraries that are 32-bit only. I was quite surprised to see that. PSARC members: Is there a requirement around 64-bit support? Or is it completely optional? Since Wyoming all libraries need to be 64 and 32 bit. Consolidations and base delivery directories. Not having both is analgous to not supporting Solaris ISA's. It's a no no. The only circumstance might be a HW device for which there is only one ISA implementation. This project must deliver all relevant ISA interfaces. If there's some dependency then that dependency needs to be resolved before the project delivers. It's fine to have a delivery dependency. 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
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Glenn Fowler gsf at research.att.com 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 should just fix the mistake ... but that's not this case. the reason for including some ast headers and .so's is that they are part of the ksh93 user runtime builtin/plugin api BTW: I did never ask to remove /usr/include/ast as the integration has been discussed and approved. I just tried to explain that things needed for an approved case need to be included in /usr/include and /usr/lib also even though some people may not like it. The main issue here is what you and David Korn mentioned for the ksh93 case but what may have forgotten: Software that has been developped in a systematic portability abstraction environment cannot be reverted to a non-portable variant at no cost and without introducing new bugs. OpenSolaris is not the world but just a part of the portability universe for free software that has been developped for more than just OpenSolaris. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
PSARC/2008/179 cross link-editor
Garrett D'Amore gdamore at sun.com 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 such autoconfiguration out of ON. I tend to believe that we have a bunch of stuff in ON, that probably should live in another consolidation. (Again, perl comes to mind... though I'm sure others have different, and perhaps equally, or more so, valid opinions.) I believe this is off topic and does not belong into PSARC. Perl may not belong into ON, but there is other software (currently from other consolidations) that logically belong into ON. ON should be self-contained and complete enough to be used in GUI-less embedded systems. It should only contain software with a free enough license for embedded usage. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
PSARC/2008/179 cross link-editor
Nicolas Williams Nicolas.Williams at sun.com 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 to say this, but it makes cross compilation harder than people may expect. Many people believe that cross compilation is easy because the GNU autoconf documentation incorrectly claims this is something that works by default. In fact, GNU autoconf provides some basic fallback definitions that apply for Linux and that may allow to compile a piece of software on a different Linux platform. If you like or need to go beyond this, you start hand crafting the autoconf results. For Solaris we generally do not use auto configuration; this includes even things like perl. Certainly the bits which are used initial bringup do not depend on auto configuration; that may change if ksh93 becomes more important but if cross-compiling for architecture ports becomes a requirement for ON, then something will have to give. But that's neither here nor this case. Casper
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
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 proposed delivering more. In particular it had a daemon that provided remote scanner access. This case is just the library. 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. Why is it that this case needs to do these things but integration of webcam support, pilot-xter, gphoto etc didn't ? The answer isn't because it was missed it is because they are just end user applications using libusb. This case is JUST an application library (libsane) that runs as the user. As such I don't see how it is any different to any other libusb consumer such as gphoto or gnome-pilot, pilot-xfer. The access control to the libusb provided devices that these libraries and end user programs use is done by the following /etc/logindevperm entry: /dev/console0600/dev/usb/[0-9a-f]+[.][0-9a-f]+/[0-9]+/* driver=scsa2usb,usb_mid,usbprn,ugen #libusb/ugen devices If you think that is wrong then the issue is with the whole architecture of libusb and the ugen driver not the architecture of this case. -- Darren J Moffat
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
James Carlson james.d.carlson at sun.com 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 don't think there's any similar third-party plug-in consideration for libschily, is there? libfind+libschily export a find(1) interface that can be used as a ksh93 plugin if someone writes a 5-line wrapper program. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
unzoo integration [PSARC/2008/183 FastTrack timeout 03/14/2008]
Garrett D'Amore gdamore at sun.com 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 desirable for a number of reasons.) I know of at *least* two possible such implementations, including yours. I know of at least 5 different implementations, including mine. It would be a nice idea to think about how to deal with this if we did like to make all of them available on OpenSolaris. BTW: Glenn Fowler mentioned star wars, but pax(1) was the peace after the tar wars to the beginning of the 90s. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout
Glenn Fowler gsf at research.att.com 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 should just fix the mistake ... but that's not this case. the reason for including some ast headers and .so's is that they are part of the ksh93 user runtime builtin/plugin api BTW: I did never ask to remove /usr/include/ast as the integration has been discussed and approved. I just tried to explain that things needed for an approved case need to be included in /usr/include and /usr/lib also even though some people may not like it. The main issue here is what you and David Korn mentioned for the ksh93 case but what may have forgotten: Software that has been developped in a systematic portability abstraction environment cannot be reverted to a non-portable variant at no cost and without introducing new bugs. OpenSolaris is not the world but just a part of the portability universe for free software that has been developped for more than just OpenSolaris. J?rg Right, but provided whatever the build system is wouldn't need to be butchered too badly to pass an additional -I _private_include_dir_ to the compiler, that's a different issue from whether or not the headers (and which headers perhaps) should be exposed to the end user, esp. since like it or not, users tend to regard visible headers as implicit documentation. I think what people are trying to say is that when cases are in place for use of libfind, librmt, libschily, etc that are _not_ project or consolidation private or contracted, and when the interfaces exposed by the headers have proposed taxonomies, _then_ there's a good basis for putting them in a public location, but not necessarily before then. Just because the code is open source doesn't automatically make it a good idea to put the headers where J. Random Hacker can find them even without downloading source, and simply assume that he can expect cool dependencies on them from other platforms to be supported on Solaris. And just because there are plenty of headers already in /usr/include that describe more than just documented interfaces, doesn't make putting more out there a good thing. At least that's my attempt at understanding and rephrasing what I've read thus far, and notwithstanding my speaking only for myself, I think it's a reasonable enough position not to encourage use of something in ways that are not (or not yet) supported. This message posted from opensolaris.org
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Joseph Kowalski jek3 at sun.com 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 schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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? Gary..
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Joseph Kowalski jek3 at Sun.COM 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 they are not provided by the star integration, I am OK with that. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
LSARC 2007/698 pgBouncer
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
Nethack 3.4.3 [PSARC/2008/172 FastTrack timeout 03/11/2008]
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 in ~, or something.) *-config only exist for backwards compatibility in most packages now, because some engineering was done several years ago, and most packages have moved to providing *.pc data files used by the common pkg-config command. Compare the number of files in /usr/lib/pkgconfig to the number of /usr/bin/*-config commands and learn just what you were saved from. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
PSARC/2008/179 cross link-editor
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. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Nethack 3.4.3 [PSARC/2008/172 FastTrack timeout 03/11/2008]
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 common registry, or dot files in ~, or something.) *-config only exist for backwards compatibility in most packages now, because some engineering was done several years ago, and most packages have moved to providing *.pc data files used by the common pkg-config command. Compare the number of files in /usr/lib/pkgconfig to the number of /usr/bin/*-config commands and learn just what you were saved from. In a word, Yay! -- Garrett
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Garrett D'Amore gdamore at sun.com 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 you like to use remote tape access. I am not sure whether software that does not use librmt is able to deal with this at all. Maybe integration into ON is superior here. Particularly if there is a belief that star might one day replace some other Solaris archiver (pax?) (It does strike me as unfortunate that we have three commands that serve the same basic purpose -- cpio, pax, and tar, with three different source bases, at least one of which remains closed.) 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. The other issue is that integration into ON (with its more stringent delivery requirements) may be more work than the project team (whether Ken, Joerg, or other parties) is willing to take on. However, doing the work now might simplify future matters, such as making ufsdump/ufsrestore librmt aware. (Hmm... its even possible, I suppose, that at that point it might be possible to do *that* change with very little, or even no, ARC case work... just using private APIs within ON.) It would be sufficient to write Solaris (ON) specific makefiles for star and the rest of the code. I would need some help for this and a bit more help on how the autoconfiguration stuff may be integrated. I currently believe it should be run at the same time as rpcgen(1) creates some files for /usr/include/. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
PSARC/2008/179 cross link-editor
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. For bootstrapping an Emerging Platform, there's no need to even attempt to compile everything, right? Cross-compile that what you minimally need to start running the rest; that may even be less than ON. Casper
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Joerg Schilling wrote: Joseph Kowalski jek3 at Sun.COM 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 they are not provided by the star integration, I am OK with that. J?rg We'll fix all manpages to accurately reflect what we are shipping. -ken -- Ken Erickson | kene at Eng.Sun.COM Sun Microsystems, Inc., Solaris OS Engineering | Voice: (847)663-9471 4150 Network Circle MS UITA01| Cell: (847)530-4603 Santa Clara, CA 95054| If you want me to read something, don't send it as a StarOffice or HTML attachment.
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Joerg Schilling wrote: Garrett D'Amore gdamore at sun.com 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 you like to use remote tape access. I am not sure whether software that does not use librmt is able to deal with this at all. OK, thanks for the clarification. (I've already realized my error about /etc/rmt being in the network protocol... too bad I guess.) Maybe integration into ON is superior here. Particularly if there is a belief that star might one day replace some other Solaris archiver (pax?) (It does strike me as unfortunate that we have three commands that serve the same basic purpose -- cpio, pax, and tar, with three different source bases, at least one of which remains closed.) 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 make star do all this, integrate well into Solaris (and probably ON), then I'm all for going down this route. As a question, what is your take on dealing with possible code forks here? I.e. if Solaris needs/wants some change to the source code at some point in the future, how happy will you be to accommodate such a change, even if it is not necessarily best for the portable version of the code? (I don't have anything specifically in mind, other than perhaps the automatic configuration bits.) Being in ON would mean, ultimately, that other people could be making changes to the source, without a guarantee of the bits being pushed upstream (though I would really hope any RTI advocate would be savvy enough to ask that you were at least included in the code review -- I know I would -- but there wouldn't be a *guarantee* that this would happen). The other issue is that integration into ON (with its more stringent delivery requirements) may be more work than the project team (whether Ken, Joerg, or other parties) is willing to take on. However, doing the work now might simplify future matters, such as making ufsdump/ufsrestore librmt aware. (Hmm... its even possible, I suppose, that at that point it might be possible to do *that* change with very little, or even no, ARC case work... just using private APIs within ON.) It would be sufficient to write Solaris (ON) specific makefiles for star and the rest of the code. I've refrained from offering to do so in the past, but if ultimately this becomes the major stumbling block, I'll volunteer to help out here. As byzantine as ON's build system is, it has become mostly familiar to me over the course of time. (Some of the library related makefile stuff and CTF support in the kernel still seems like voodoo to me, but I seem to be able to manage.) I would need some help for this and a bit more help on how the autoconfiguration stuff may be integrated. I currently believe it should be run at the same time as rpcgen(1) creates some files for /usr/include/. My strong preference is to avoid use of autoconfiguration in ON if at all possible. The reasons for this are: 1) autoconfiguration significantly increases compile times 2) autoconfiguration adds a layer of complexity that makes it harder to support if you don't need portability (nothing in ON needs it) 3) autoconfiguration can hinder cross-platform portability (c.f. the earlier cross-compilation dicussion) However, I'm totally fine with the idea that the build process can take certain source files which may not be in C, and massage them into compilable C code -- provided that the results are not subject to change depending on the machine used to do the compilation. I think this is true for rpcgen, and I know it is true for other similar tools like lex and yacc. (Other solutions exist as well, such as custom sed/awk/perl scripts, use of m4 or cpp, etc. Care needs to be taken to avoid depending on the development machine though.) -- Garrett
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
One not unimportant question: does librmt support anything other than rshd? sshd would be nice. Casper
LSARC 2007/698 pgBouncer
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 short answer is to compile with: -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ and link with -lxnet instead of the usual -lsocket -lnsl. -- James Carlson, Solaris Networking james.d.carlson at sun.com Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
2008/159 svcs -xq
[final revision, take two - /hopefully/] Someone pointed out a grammatical issue in the EXIT STATUS section. s/which/that/ svcs -xq Mark Martin 27 February 2008 1. Summary An unnamed customer has requested an enhancement to svcs -x output which produces no output but would set the error level to 0 if there are no services in a problematic state and a non-zero result if svcs -x would actually produce an output. This enhancement provides an additional -q flag to to the svcs command which quietens svcs -x output and allows easier integration with admin scripts which may only need to know if there are either 0 or at least one service in a problematic state and do not want to parse svcs -x output. It should be noted that this optional flag would emulate the similar -q flag in svcprop, a related SMF command. 2. Interface table Interface Stability - - svcs -xq (q option letter) Committed svcs -x return code Committed This case requests Patch binding for these interfaces. 3. References PSARC 2004/673 svcs -x (eXplain) 4. Manual page differences SYNOPSIS -svcs -x [-v] [FMRI]... + svcs -x [-q] [-v] [FMRI] DESCRIPTION The fourth form explains the states of service instances. For each argument, a block of human-readable text is displayed which explains what state the service is in, and why it is in that state. With no arguments, problematic ser- vices are described. + If the optional -q is provided in the fourth form, the command + produces no human-readable text and simply returns an error + code indicative of the existence of problematic services. With + this flag, an error code of 3 indicates services exist that are in + a maintenance state or are blocking other enabled services, + whereas an error code of 0 indicates no services in the + maintenance state. EXIT STATUS + + 3Services exist that are in the maintenance state or +are blocking other enabled services. -- next part -- An HTML attachment was scrubbed... URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080312/8e6b226f/attachment.html
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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. -- Garrett
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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 whatever-program . J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
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..
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Gary Winiger gww at eng.sun.com 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/arc/policies/SMF-policy/ what the justification for add a default file? What's the auditable administrative interface? See the audit policy: http://opensolaris.org/os/community/arc/policies/audit-policy/ for the administrative interface? BSD rmt(8) from MacOS 10.5.2 doesn't seem to require a defaults file. Nor does rmt(1M). 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 implementaions, you need to tdo this via /etc/default/rmt 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's /etc/default/star is an extension to the _documented_ part of Sun's /etc/default/tar. If called as tar or suntar, star checks /etc/default/tar instead of /etc/default/star. Interfaces: ./star-symtable locationCommitted ./star-symdump locationCommitted ./star-tmpdir locationCommitted ./star-lock locationCommitted Is this saying that if I use star(1), I get 4 turds[tm] dropped in cwd that I have to clean up at every use? This has been answered yesterday, please read the old mail. Specifically, it seems poor architecture to drop lock or other temporaty files in cwd. If use of incremental star must be serialized, putting the files necessary in a tmpfs (/tmp) would be a far preferable architecture to me. What happens if the system crashes during an incremental star? Are these files automatically cleaned up on reboot? Check man ufsrestore for comparative information. /etc/rmtsymlink to /usr/sbin/rmt Committed 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. /etc/init is a well known binary. Changing the location of init does not break things as it is a local decision. Changing the location of rmt breaks things. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Andrew Gabriel Andrew.Gabriel at Sun.COM 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 somehost /etc/rmt under the covers, so /etc/rmt is part of the rmt protocol. 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. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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 desirable. Dworkin's reply: You are completely correct as far as you go. Originally, the binary lived in /etc/rmt (at Berkeley and I'm pretty sure Sunos 3.x; certainly in earlier releases). There was a big push to make / as small as possible in Sunos 4.x, so it got moved from /etc to /usr/etc and a symlink dropped in. I'm not sure when it moved from /usr/etc to /usr/sbin, but the SCCS history suggests it was put there as part of the original SVr4/5.0 work. Margot 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 somehost /etc/rmt under the covers, so /etc/rmt is part of the rmt protocol. Given that rmt is never invoked directly as a command as far as I'm aware, it's not clear to me that /usr/sbin/rmt is the right location for the real binary. Somewhere in /usr/lib/ might be more appropriate.
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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 whatever-program . Hm, OK. I think we're doing an as-is open source integration so I guess that is fine. A ~/.librmtrc would be nice too. I'm on the fence on a more distinctive name; RSH is sufficiently clear, I think, that other programs which default to rsh use could reuse it (think rdist). Casper
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Gary Winiger gww at eng.sun.com 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)? If not what's missing? If called as tar, star supports the functionality of Sun's tar with a few exceptions. Once, star is in OpenSolaris, I hope this is no longer a rabbit and hedgehog play. There is currently no support for Sun's ACL/extended-attribute archive format that is based on outdated technology. Star however supports a _portable_ ACL archive format that is based on recent POSIX technology for vendor specific extensions. The problem with the trusted Solaris extensions is that they are undocumented. Let us discuss the application interface to make it fit nicely into star and let us define an archive format for these extensions. I see no reason why this cannot be implemented. I am also interested in discussing the archive format for extended attribute files. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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.
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Gary Winiger gww at eng.sun.com 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/arc/policies/SMF-policy/ what the justification for add a default file? What's the auditable administrative interface? See the audit policy: http://opensolaris.org/os/community/arc/policies/audit-policy/ for the administrative interface? BSD rmt(8) from MacOS 10.5.2 doesn't seem to require a defaults file. Nor does rmt(1M). 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 implementaions, you need to tdo this via /etc/default/rmt See the SMF policy relative to new /etc configuration files. See the Audit policy for administrator audit requirements. 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's /etc/default/star is an extension to the _documented_ part of Sun's /etc/default/tar. If called as tar or suntar, star checks /etc/default/tar instead of /etc/default/star. Again see above. This is a prime opportunity to do away with existing turds[tm] and move into the new age. Interfaces: ./star-symtable locationCommitted ./star-symdump locationCommitted ./star-tmpdir locationCommitted ./star-lock locationCommitted Is this saying that if I use star(1), I get 4 turds[tm] dropped in cwd that I have to clean up at every use? This has been answered yesterday, please read the old mail. Later today. Specifically, it seems poor architecture to drop lock or other temporaty files in cwd. If use of incremental star must be serialized, putting the files necessary in a tmpfs (/tmp) would be a far preferable architecture to me. What happens if the system crashes during an incremental star? Are these files automatically cleaned up on reboot? Check man ufsrestore for comparative information. IIRC ufsrestore is only for admins. Is the architecure that incremental star can only be used by admins? Gary..
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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's /etc/default/star is an extension to the _documented_ part of Sun's /etc/default/tar. If called as tar or suntar, star checks /etc/default/tar instead of /etc/default/star.
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
...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 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 desirable. Dworkin's reply: You are completely correct as far as you go. Originally, the binary lived in /etc/rmt (at Berkeley and I'm pretty sure Sunos 3.x; certainly in earlier releases). There was a big push to make / as small as possible in Sunos 4.x, so it got moved from /etc to /usr/etc and a symlink dropped in. I'm not sure when it moved from /usr/etc to /usr/sbin, but the SCCS history suggests it was put there as part of the original SVr4/5.0 work. Margot 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 somehost /etc/rmt under the covers, so /etc/rmt is part of the rmt protocol. Given that rmt is never invoked directly as a command as far as I'm aware, it's not clear to me that /usr/sbin/rmt is the right location for the real binary. Somewhere in /usr/lib/ might be more appropriate.
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
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 proposed delivering more. In particular it had a daemon that provided remote scanner access. This case is just the library. I'm looking for dependences here. In one hand we have a stalled case that seems to have overlap. 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 when done. Solaris Object Reuse needs to be supported. Gary..
2008/159 svcs -xq
This case was approved during ARC business today. liane
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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 gww at eng.sun.com 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/arc/policies/SMF-policy/ what the justification for add a default file? What's the auditable administrative interface? See the audit policy: http://opensolaris.org/os/community/arc/policies/audit-policy/ for the administrative interface? BSD rmt(8) from MacOS 10.5.2 doesn't seem to require a defaults file. Nor does rmt(1M). 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 implementaions, you need to tdo this via /etc/default/rmt See the SMF policy relative to new /etc configuration files. See the Audit policy for administrator audit requirements.
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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 socket permission error. (Haven't checked the code so it may well work correctly. Note that inside Solaris we use some tricks with a mutual understanding between the commands using rcmd(3) [rdist, ufsdump, ufsrestore, rsh, rlogin] which cause privilege juggling at the appropriate points in the rcmd(3) library call's guts. It internally uses privport_ok() which checks for Solaris privileges in case of #ifdef HAVE_GETPPRIV J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Gary Winiger gww at eng.sun.com 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 implementaions, you need to tdo this via /etc/default/rmt See the SMF policy relative to new /etc configuration files. See the Audit policy for administrator audit requirements. See portability issues What happens if the system crashes during an incremental star? Are these files automatically cleaned up on reboot? Check man ufsrestore for comparative information. IIRC ufsrestore is only for admins. Is the architecure that incremental star can only be used by admins? Star's incrementals can be used by anyone who has the needed permissions for the files to handle. If you use star level=1 -cumulative you may need to keep the files in question for many years to allow to restore future incrementals. I know of no better location than the top level restore directory. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
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 reference? The LSARC case proposed delivering more. In particular it had a daemon that provided remote scanner access. This case is just the library. I'm looking for dependences here. In one hand we have a stalled case that seems to have overlap. 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 when done. Solaris Object Reuse needs to be supported. Consider that if I grab the libsane source and compile and built all as a normal user; I need no privileges to access the scanner because logindevperm already gave me as the console user ownership of the device nodes. So best I can tell there is nothing this case, it just provides library, can do to change this. 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 user logs in. -- Darren J Moffat
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
On Wed, 12 Mar 2008 18:00:27 +0100 Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) wrote: Garrett D'Amore Garrett.Damore at Sun.COM 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 make star do all this, integrate well into Solaris (and probably ON), then I'm all for going down this route. As a question, what is your take on dealing with possible code forks here? I.e. if Solaris needs/wants some change to the source code at some point in the future, how happy will you be to accommodate such a change, even if it is not necessarily best for the portable version of the code? (I don't have anything specifically in mind, other than perhaps the automatic configuration bits.) This is a very similar issue to what applies to ksh93. Adding new code without looking at portability creates a fork that make the software hard to maintain. just as ksh93 provides a user builtin/plugin api for extending ksh93 I would recommend a plugin api for adding addtional archive formats to pax with judicious use of runtime .so plugins new archive formats could be supported without ever recompiling the pax a.out plugins could even handle closed source archivers by converting pax options to the closed source a.out options on the fly (e.g., a pax wrapper around zoo implemented as a plugin) -- Glenn Fowler -- ATT Research, Florham Park NJ --
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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'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. -- Darren J Moffat
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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 have to navigate those waters on your own. Propose something reasonable. ;-} -- James Carlson, Solaris Networking james.d.carlson at sun.com Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
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 when done. Solaris Object Reuse needs to be supported. Scanners are different with removable media we usually think of (e.g., a CD Rom). In CD Rom case, when a CD is inserted, it will be mounted without user operations and HAL addon/callouts will work. In scanner case, nothing will happen when removable stuff is put in it. Users run the sane application to start all the jobs. And then, the scan job is done when sane is done. Therefore, sane is just an user application which access scanner device through libusb/ugen stack, that's it. I can not see the must relationship between sane and HAL. Colin
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
On Wed, Mar 12, 2008 at 12:11 PM, Joerg Schilling Joerg.Schilling at fokus.fraunhofer.de wrote: Gary Winiger gww at eng.sun.com 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 implementaions, you need to tdo this via /etc/default/rmt See the SMF policy relative to new /etc configuration files. See the Audit policy for administrator audit requirements. See portability issues Part of the value add of Solaris is modifying software to use Solaris-specific functionality. Adding SMF, etc. does not affect the portability here if done properly. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ To err is human -- and to blame it on a computer is even more so. - Robert Orben
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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 member, telling them that is basically saying screw you, you'll never get it from us.They can't add a service request, and can't escalate it - that's the process for customers, not the community. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Nethack 3.4.3 [PSARC/2008/172 FastTrack timeout 03/11/2008]
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.) 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 of entries in /usr/lib used to be much more of a performance issue than /usr/bin ever was (ld.so.1 does a lot more stats than sh). I don't know the current state (maybe fast caches lower this into the noise.) - jek3
Nethack 3.4.3 [PSARC/2008/172 FastTrack timeout 03/11/2008]
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 of entries in /usr/lib used to be much more of a performance issue than /usr/bin ever was (ld.so.1 does a lot more stats than sh). I don't know the current state (maybe fast caches lower this into the noise.) Oh sure, I would be happy with /usr/lib/exec or /usr/libexec, or /usr/lib/pkg/... But I thought that all executables not to be run by users or sysadmins (e.g., daemons started by SMF) go into /usr/lib (having recently delivered such a thing...). Nico --
Nethack 3.4.3 [PSARC/2008/172 FastTrack timeout 03/11/2008]
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.
Nethack 3.4.3 [PSARC/2008/172 FastTrack timeout 03/11/2008]
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 interfaces. Oh well hopefully its helping to win hearts and minds somewhere, or something like that. Be careful here. *We* are now a FOSS group. You shouldn't paint all FOSS groups with a broad brush. I think the issue is that we don't do a good enough job of vetting the quality/supportability/stability of FOSS. This *has always* been part of the job, dating back to the original include FOSS in Solaris cases. This requirement hasn't changed. Note that this is the same basic problem for Ubuntu, RedHat, whoever... Solaris just has (had?) a higher bar. The other problem is that Solaris isn't Linux. It often takes some work to port Linux targeted FOSS to advanced Solaris facilities. Maybe we could help with a document or check list of these things. I suspect FOSS maintainers get rather annoyed when the first time they find out of such things is by the ARC or the c-teams. On the other side, the maintainers should understand that it often takes more than recompile to be part of the OpenSolaris community. I think FOSS guys can be neat. I'd even let my daughter marry one (after I checked his background). :-) However, this is a different thread (er, not the digression from the digression from the `not this case` discussion). I just felt that we should be careful to not be pejorative to FOSS. - jek3
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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- close to 20. They have also been around awhile too; /etc/default/rmt - 1998 and /etc/default/star - 2000. Thanks, Margot James Carlson wrote: 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 have to navigate those waters on your own. Propose something reasonable. ;-}
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
On Wed, Mar 12, 2008 at 1:26 PM, Margot Miller margot.miller at sun.com 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 well-known for administrators across a wide set of operating systems- close to 20. They have also been around awhile too; /etc/default/rmt - 1998 and /etc/default/star - 2000. Right, but /etc/rc.d, etc. were around for decades as well, but have been moved to SMF. While I agree familiarity is sometimes beneficial, I personally think leveraging some of the more advantageous technologies that Solaris provides it is of greater benefit to users than just familiarity. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ To err is human -- and to blame it on a computer is even more so. - Robert Orben
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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 intellectual property, HW support, ...
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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 member, telling them that is basically saying screw you, you'll never get it from us.They can't add a service request, and can't escalate it - that's the process for customers, not the community. Sorry, that wasn't my intent. Community members should be able to say they are affected by an existing bug just the same as any other Solaris user. If they can, there's something broken in the OS.O processes. Community members are permitted to fix existing bugs or bugs they file. If there's a bug in a gate (docs in this case) supplying a suggested fix and asking for someone in docs to integrate seems appropriate. There is a responsible engineer (RE) on this bug. I suspect the RE would be more than happy to accept suggested fixes from where ever they come. Gary..
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Joerg Schilling wrote: Joseph Kowalski jek3 at Sun.COM 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 they are not provided by the star integration, I am OK with that. J?rg Sorry, I got a bit too emphatic. You know,... *all*. Deleting the lib manpages is probably sufficient. Ken, you're probably more familiar with the documentation. Do you believe that just deleting the lib manpages is sufficient? Sorry about yelling... - jek3
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Joerg Schilling wrote: Joseph Kowalski jek3 at Sun.COM 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 they are not provided by the star integration, I am OK with that. J?rg / /I re-read this (when I got my third copy... :-) ) Its Sun/Solaris policy to not document private interfaces (that would be the next case). 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... - jek3
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
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 you think this means object reuse applies here; my understanding was that object reuse applied to reusable read/write storage like disks memory -- if user A frees a page, and the system recycles it and gives it to user B, user B better not find any of user A's data in the page. the removable stuff in a typical scanner is not writable by the scanner. (all in one devices with both scanner and printer typically have separate paper paths for print vs. scan). There is nothing SOFTWARE can do about people who left something on the scanner bed when they logged out and wandered off. 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. - Bill
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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 an OpenSolaris community member, telling them that is basically saying screw you, you'll never get it from us.They can't add a service request, and can't escalate it - that's the process for customers, not the community. Sorry, that wasn't my intent. Community members should be able to say they are affected by an existing bug just the same as any other Solaris user. If they can, there's something broken in the OS.O processes. There is much broken in the opensolaris.org bug processes, and a large project in place to fix them, by replacing use of bugster with the external bugzilla, but there's a lot of work to get from here to there. Until then, assume that bugs are file-once-and-read-only-afterwards (and read only of the description, not the comments, suggested fix, or evaluation) to community members. Even then, escalating a bug is part of a support contract process, not something even internal engineers can do on their own. Community members are permitted to fix existing bugs or bugs they file. If there's a bug in a gate (docs in this case) supplying a suggested fix and asking for someone in docs to integrate seems appropriate. There is a responsible engineer (RE) on this bug. I suspect the RE would be more than happy to accept suggested fixes from where ever they come. 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. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Joseph Kowalski wrote: Joerg Schilling wrote: Joseph Kowalski jek3 at Sun.COM 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 they are not provided by the star integration, I am OK with that. J?rg / /I re-read this (when I got my third copy... :-) ) Its Sun/Solaris policy to not document private interfaces (that would be the next case). 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... - jek3 I will be sure the manpages we ship only document the interfaces we agree should be public. Joerg has already said he doesn't have a problem with me editing the manpages. -ken -- Ken Erickson | kene at Eng.Sun.COM Sun Microsystems, Inc., Solaris OS Engineering | Voice: (847)663-9471 4150 Network Circle MS UITA01| Cell: (847)530-4603 Santa Clara, CA 95054| If you want me to read something, don't send it as a StarOffice or HTML attachment.
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
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 not understanding why you think this means object reuse applies here; my understanding was that object reuse applied to reusable read/write storage like disks memory -- if user A frees a page, and the system recycles it and gives it to user B, user B better not find any of user A's data in the page. the removable stuff in a typical scanner is not writable by the scanner. (all in one devices with both scanner and printer typically have separate paper paths for print vs. scan). Not only separate paper paths but they often appear as separate USB devices (using usb_mid(7D) on Solaris, and usbprn(7D) for the printer part). I wonder how we do object reuse scrubbing for a webcam ? Ask the user to put a cloth over the camera ;-) -- Darren J Moffat
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Joerg Schilling wrote: Gary Winiger gww at eng.sun.com 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)? If not what's missing? If called as tar, star supports the functionality of Sun's tar with a few exceptions. Once, star is in OpenSolaris, I hope this is no longer a rabbit and hedgehog play. Are there other exceptions other than those addressed below? So, for the purposes of documentation I'd like to see the exceptions noted. There is currently no support for Sun's ACL/extended-attribute archive format that is based on outdated technology. Star however supports a _portable_ ACL archive format that is based on recent POSIX technology for vendor specific extensions. I can understand reasons for not writing Solaris format archives, but what prevents star or the OpenSolaris star project from reading Solaris format archives? Lack of interest may be a satisfactory answer, but there are those who already have tar-like archives from Solaris. From what you've indicated, star supports an archive format WRT ACLs that readable and usable by tar implementations on other OSs (other than a star implementation). Is that correct? The problem with the trusted Solaris extensions is that they are undocumented. Let us discuss the application interface to make it fit nicely into star and let us define an archive format for these extensions. I see no reason why this cannot be implemented. I am also interested in discussing the archive format for extended attribute files. Joerg, I and others are interested in discussing archive format (tar-like) for various applications within Solaris and OpenSolaris. Portability of format is a big deal. Is there a OpenSolaris or other discussion forum in which these are being discussed? J?rg -- - Rick Matthews email: Rick.Matthews at sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USAmain: +1(651) 554-1500 -
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Alan Coopersmith Alan.Coopersmith at Sun.COM 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. I am interested in the documentation that allow engineers to work on top of the library functions that support the trusted extensions. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Joseph Kowalski jek3 at sun.com 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 documentation. If someone at Sun removes the information or hints, I am OK with it as long as the documentation for the supplied programs is kept. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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 docs that I know of. The source is easy: http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/head/tar.h http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/tar/tar.c PSARC/2005/723 Solaris Trusted Extensions Filesystem Labeling has pretty much the same information as tar.h Archiving Labeled Filesystems = The labels of file and directories can be archived using the -T extension to tar. The labels are stored in the same ancillary file currently used to store ACLs. Such labeled tar archives are backward compatible with Trusted Solaris 8. The following attribute types were used in Trusted Solaris 8: /* * Attribute types used in TS 8, TS 2.5 ancillary files. */ #define LBL_TYPE'L' /* CMW label data type in ancillary file */ #define APRIV_TYPE 'P' /* allowed privileges data type in file */ #define FPRIV_TYPE 'p' /* forced privileges data type in file */ #define COMP_TYPE 'C' /* path components, use for MLD */ #define DIR_TYPE'D' /* directory data type in file */ #define ATTR_FLAG_TYPE 'F' /* file attribute flag bytes data type */ #define LK_COMP_TYPE'K' /* link data path component */ Rampart interprets these attribute types, however, restoring such archives is subject to a number of restrictions. For example, the APRIV_TYPE, FPRIV_TYPE, and ATTR_FLAG_TYPE are ignored. Multilevel and single level directory specifications from Trusted Solaris 8 are converted into zone relative pathnames when possible. Because labels of files cannot be changed in place, labeled files can only be restored to directories with the same label as specified in the archive. Labeled tar archives produced on a Rampart system only make use of the DIR_TYPE and LBL_TYPE formats, but are backward compatible. Gary..
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Joerg Schilling wrote: Garrett D'Amore Garrett.Damore at Sun.COM 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 make star do all this, integrate well into Solaris (and probably ON), then I'm all for going down this route. As a question, what is your take on dealing with possible code forks here? I.e. if Solaris needs/wants some change to the source code at some point in the future, how happy will you be to accommodate such a change, even if it is not necessarily best for the portable version of the code? (I don't have anything specifically in mind, other than perhaps the automatic configuration bits.) This is a very similar issue to what applies to ksh93. Adding new code without looking at portability creates a fork that make the software hard to maintain. Believe me, I understand this. But I also understand that there are different models for software maintenance here. Model one is that the canonical source is upstream, as few changes as possible are made to the software (none if possible), and if changes are needed, they are made at the upstream source. This model is typically inappropriate for ON, and is most useful with 3rd party packages needing little or no change. Model two is that the canonical source lives in OpenSolaris, and maintenance of the code can take place there. There may or may not be upstream sources to which further changes are fed. This model is used for software where Sun/Solaris/OpenSolaris staff are able and willing to maintain a separate copy, and is often the case where Sun can make support guarantees to customers. There are probably other hybrid approaches as well. But if you're going to go into ON, it would be good if we could follow model two. If we're stuck with model one, then you should probably consider abandoning the notion that star will replace /bin/tar (at least for Sun Solaris -- the ability to make Solaris specific features is too important, and OpenSolaris can't block bug fixes or progress on Joerg Schilling -- any more than they could block on Garrett D'Amore.) Note when I had my own software to contribute (afe, mxfe as examples) I chose model two . Other people can work on it without talking to me, but I *hope* that they will consult me. (I'll probably complain to the RTI advocate that lets someone putback changes to that code without chatting with me first. But technically, I might not have much justification for such a complaint.) Being in ON would mean, ultimately, that other people could be making changes to the source, without a guarantee of the bits being pushed upstream (though I would really hope any RTI advocate would be savvy enough to ask that you were at least included in the code review -- I know I would -- but there wouldn't be a *guarantee* that this would happen). If people like to make changes, they should discuss it first. This is similar to an Solaris ARC case. Changes must not affect compatibility and should be aligned with the planned future development. They *should*, yes. This is not the same as *must*. See my earlier comments about RTI advocacy, though. If you want to retain absolute control over star (and if it has a true open source license, then you simply cannot -- forks are always possible), then perhaps you might want to rethink the whole idea of integration. It would be sufficient to write Solaris (ON) specific makefiles for star and the rest of the code. I've refrained from offering to do so in the past, but if ultimately this becomes the major stumbling block, I'll volunteer to help out here. As byzantine as ON's build system is, it has become mostly familiar to me over the course of time. (Some of the library related makefile stuff and CTF support in the kernel still seems like voodoo to me, but I seem to be able to manage.) OK I would need some help for this and a bit more help on how the autoconfiguration stuff may be integrated. I currently believe it should be run at the same time as rpcgen(1) creates some files for /usr/include/. My strong preference is to avoid use of autoconfiguration in ON if at all possible. The reasons for this are: 1) autoconfiguration significantly increases compile times This is not true if you do it like I do: one autoconf for all software and autoconf is controlled by make rules. Have you got measurements showing this? I'm skeptical. (autoconf does caching as well, but you still have to do the initial collection and analysis.) The exception to this would be if you collected once for *all* of ON, and everyone used those results. I don't think that's what you're proposing
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
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 you think this means object reuse applies here; my understanding was that object reuse applied to reusable read/write storage like disks memory -- if user A frees a page, and the system recycles it and gives it to user B, user B better not find any of user A's data in the page. Huh: T.RESIDUAL_DATA A user or process may gain unauthorized access to data through reallocation of TOE resources from one user or process to another. O.RESIDUAL_INFORMATION The TOE will ensure that any data contained in a protected resource is not available when the resource is reallocated. Rationale The sharing of hardware resources such as primary and secondary storage components between users introduces the potential for information flow in violation of the TOE security policy when hardware resources are deallocated from one user and allocated to another. In order to prevent such unintended consequences, the TOE prevents the compromise of the TOE security policy through mechanisms that ensure that residual information cannot be accessed after the resource has been reallocated (O.RESIDUAL_INFORMATION). The intent here is to prevent the unauthorized flow of information that would violate the TOE security policy. The intent is not to require explicit scrubbing or overwriting of data prior to reuse of the storage resource. Therefore, the presence of residual data in a storage resource is acceptable as long as it cannot be accessed by subsequent users such that a violation of the TOE security policy results. Note, however, that the requirements for storage resources which contain critical cryptographic security parameters differ from the requirements for other types of data. Refer to the appropriate threat, objectives, and requirements rationale for a discussion of the requirements for residual data protection involving critical cryptographic security parameters. Residual Information Protection (FDP_RIP) Full Residual Information Protection (FDP_RIP.2) FDP_RIP.2.1 Refinement: The TSF shall ensure that any previous information content of a resource is made unavailable upon the [selection: allocation of the resource to, deallocation of the resource from] all objects other than those associated with cryptographic keys and critical cryptographic security parameters as described in FCS_CKM.4.1 and FCS_CKM_EXP.2.5. Application Note: This requirement applies to all resources except for cryptographic keys and critical cryptographic security parameters governed by or used by the TSF; it includes resources used to store data and attributes. It also includes the encrypted representation of information. Residual information protection for cryptographic data is covered in class FCS. Application Note: Clearing the content of resources on deallocation is sufficient to satisfy this requirement, provided that unallocated resources will not accumulate new information until they are allocated again. the removable stuff in a typical scanner is not writable by the scanner. Writability isn't the issue. Consider cryptographic keys that are stored in read only memory. When you give that memory to another process would you want those keys to ge readable by that process? There is nothing SOFTWARE can do about people who left something on the scanner bed when they logged out and wandered off. As broken as you may consider removable media management and device allocation are there to address the things that can't be done in other forms. 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 allocation subsystem is in effect, the user is required to be authorized, chkauthattr(3SECDB) to have access to devices under its control. 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..
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
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. Gary..
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
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 page on the scanner or is it something else? If it is the can't flush page table :-) problem, what is it that you would expect to be done here? Not allow logout to happen until scan() == empty_scan_platen() or some such? or ...? -John
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
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 allocation subsystem is in effect, the user is required to be authorized, chkauthattr(3SECDB) to have access to devices under its control. 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. Another way to deal with object reuse would be for the driver to ensure that data leftover from one use of the device is not accessible to subsequent users. That seems like a more workable solution than device allocation. A similar argument could be made about /dev/audio. Do we have reason to believe that the proposed implementation doesn't *already* comply with the object reuse requirement? Scott
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
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 which justifies delaying this case. Either: 1) there is no actual object reuse issue associated with scanners than can be dealt with in software (rather than operational procedures like signs reminding users to remove their documents from the scanner). or: 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); that inclusion allows the console user raw access to *any* USB device lacking a more specific driver. Any object reuse issue present with libsane/sane is ALSO present with just raw ugen. No change to the code this project intends to deliver can fix this hypothetical object reuse issue that exists today. This project does not make this hypothetical problem worse. This project cannot make this hypothetical problem better. - Bill
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
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 accessed after the device has been returned to the system and given to anothe person. If it is the can't flush page table :-) problem, what is it that you would expect to be done here? Not allow logout to happen until scan() == empty_scan_platen() or some such? or ...? See allocate(1), deallocate(1), device_allocate(4), device_maps(4), and I thought there was a device_clean man page that I can't find. I expect the project team to supply whatever is necessary to work within the device allocation framework so the device is properly integrated therein. This may include stuff in devfsadm(1m), mkdevalloc(1m), mkdevmaps(1m), providing a clean script/program and so on. This stuff has all been part of SunOS since 5.3. Until recently, there's been very little activity in adding system components that needed special object reuse handling. Gary..
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
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 whatever it is pointed at, and o A scanner still returns images of whatever is placed on its scanning table or run thru its document feeder. I'm pretty sure that we don't require that the audio or web camera interfaces contain code that compares the current audio or video stream with all previously processed streams to preclude the transmission of similar or identical sounds or images - all we require is that copies of those previously captured sounds or images themselves are not exposed. In a scanner, this would mean that the driver needs to dispose of all cached and buffered content, state and what have you when the device is returned to the system, but it would not require a robot arm to open up the scanner lid and remove forgotten documents from the scanning table, shred and burn them when the device is deallocated. Or, would it? -John Gary Winiger wrote: 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 accessed after the device has been returned to the system and given to anothe person. If it is the can't flush page table :-) problem, what is it that you would expect to be done here? Not allow logout to happen until scan() == empty_scan_platen() or some such? or ...? See allocate(1), deallocate(1), device_allocate(4), device_maps(4), and I thought there was a device_clean man page that I can't find. I expect the project team to supply whatever is necessary to work within the device allocation framework so the device is properly integrated therein. This may include stuff in devfsadm(1m), mkdevalloc(1m), mkdevmaps(1m), providing a clean script/program and so on. This stuff has all been part of SunOS since 5.3. Until recently, there's been very little activity in adding system components that needed special object reuse handling. Gary..
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
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 camera still shows the images of whatever it is pointed at, and o A scanner still returns images of whatever is placed on its scanning table or run thru its document feeder. I'm pretty sure that we don't require that the audio or web camera interfaces contain code that compares the current audio or video stream with all previously processed streams to preclude the transmission of similar or identical sounds or images - all we require is that copies of those previously captured sounds or images themselves are not exposed. In a scanner, this would mean that the driver needs to dispose of all cached and buffered content, state and what have you when the device is returned to the system, but it would not require a robot arm to open up the scanner lid and remove forgotten documents from the scanning table, shred and burn them when the device is deallocated. Or, would it? -John I think people are making this far more complex than it needs to be. Don't worry about paper left in the scanner or similar types of human error. The issue here is that the device needs to be effectively reset when a new user starts to use it (or at least, it needs to avoid returning data leftover from the previous user). An analogous example is /dev/audio, which has some programmable registers that retain state (e.g, for volume control). You want to make sure that one user doesn't open the device and set the registers to some state, thereby communicating information to the next user who opens the device. As I said, I would hope that the driver can guarantee the right behavior so that device allocation is not needed. Scott
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
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 allocation, that the right thing be done. This may well not the default out of the box, but there are lots of things in Solaris that we do to support configurations that are not the default out of the box. IMO, this is one of them. If when device allocation is configured all users have access to all usb devices, that's a bug and will need to be fixed by that project team. Just like other parts of Solaris, it's the delivering project team that needs to supply the parts for existing frameworks. Gary..
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
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 deallocation process (and in TX the allocation process) runs the device clean program. This instructs the user to remove any documents from the device and acknowledge they have done so. The device clean program (or the device driver) resets the device to defaults so no one accessing the device at a later time can read out device parameters, such as scanning density -- I'm hypothzing here -- at a later time. Gary..
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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 Solaris requirement. (Probably a Sun requirement, but I'm not sure about that.) I think waivers have been granted in the past (due to existing practice). Gary should verify. - jek3
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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 for adding addtional archive formats to pax with judicious use of runtime .so plugins new archive formats could be supported without ever recompiling the pax a.out plugins could even handle closed source archivers by converting pax options to the closed source a.out options on the fly (e.g., a pax wrapper around zoo implemented as a plugin) Although this is certainly a good idea, it sounds like a little bit of overkill. How often do new formats get created? A clean source level interface would seem to be good enough. The close source concerns should be transient. Just an opinion I certainly wouldn't object to a project which did what Glenn has suggested. - jek3
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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
Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]
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 user logs in. I'm guessing that this concern follows from the assertion that a scanner is removable media (to which you have already questioned). I'd like to hear if others agree with the it ain't removable media classification. - jek3
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
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 environment as LSB would like us to believe). I think the only issue is when and not if. Its not ideal, but I can accept Darren's suggestion of when (when tar - ./star). - jek3
