audiosbp16x audio driver [PSARC/2009/384 Self Review]
Garrett D'Amore - sun microsystems wrote: This project proposes to deliver a device driver for the Creative SBP16X family of AC'97 audio devices. These parts are found on the Dell OEM SoundBlaster Live! 5.1 cards (these devices will have a label of SB0200 on them.) What is the pci id's that this driver binds to. For example is it by any chance going to work for pci1102,2.1102.20.5 ? Which is what my Creative Labs SB Live! reports as. -- Darren J Moffat
PSARC/2009/374 libxmlsec
Nicolas Williams Nicolas.Williams at sun.com wrote: On Wed, Jul 01, 2009 at 11:36:33AM -0400, Brian Utterback wrote: A future ARC case could also switch us from using the OpenSSL module to a new module with more direct access to the crypto framework. Such a module would first need to be integrated in the community project. What sort of module are we talking? Where would it plug in? There already is a way to access the Solaris crypto framework more directly than via the OpenSSL PKCS#11 engine: just use libpkcs11 directly. In order to make Solaris useable out of the box for such use case, we first would need to get a working libpcsclite. What's currently delivered may support some of the Sun made java cards but it does not allow to use the standard chipcards. 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) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
PSARC/2009/374 libxmlsec
Joerg Schilling wrote: Nicolas Williams Nicolas.Williams at sun.com wrote: On Wed, Jul 01, 2009 at 11:36:33AM -0400, Brian Utterback wrote: A future ARC case could also switch us from using the OpenSSL module to a new module with more direct access to the crypto framework. Such a module would first need to be integrated in the community project. What sort of module are we talking? Where would it plug in? There already is a way to access the Solaris crypto framework more directly than via the OpenSSL PKCS#11 engine: just use libpkcs11 directly. In order to make Solaris useable out of the box for such use case, we first would need to get a working libpcsclite. What's currently delivered may support some of the Sun made java cards but it does not allow to use the standard chipcards. What is currently delivered is also EOF and I'm currently in prelim codereview to remove it. -- Darren J Moffat
PSARC/2009/374 libxmlsec
Darren J Moffat Darren.Moffat at sun.com wrote: In order to make Solaris useable out of the box for such use case, we first would need to get a working libpcsclite. What's currently delivered may support some of the Sun made java cards but it does not allow to use the standard chipcards. What is currently delivered is also EOF and I'm currently in prelim codereview to remove it. This sounds good! I am in hope that we will also get support for the springcard wireless reader so I can use it to talk to the planned new German eID card ;-) 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) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
audiosbp16x audio driver [PSARC/2009/384 Self Review]
Darren J Moffat wrote: Garrett D'Amore - sun microsystems wrote: This project proposes to deliver a device driver for the Creative SBP16X family of AC'97 audio devices. These parts are found on the Dell OEM SoundBlaster Live! 5.1 cards (these devices will have a label of SB0200 on them.) What is the pci id's that this driver binds to. For example is it by any chance going to work for pci1102,2.1102.20.5 ? Which is what my Creative Labs SB Live! reports as. No this driver will not work for pci1102,2. That driver is under development. regards Dev -- --- 4Front Technologies 9826 Beverlywood Street Los Angeles, CA 90064, USA Tel: (310) 202 8530 Fax: (310) 202 0496
2009/387 [Pathname Reparse Points]
Darren J Moffat wrote: This looks very cool but I haven't quite got my head around it completely yet. What happens if open(2) is called with O_NOFOLLOW set on one of these reparse points ? (Please answer for ZFS local access, NFS and CIFS). Since these reparse points are implemented with a special type of symlink, open() with O_NOFOLLOW should fail with such an object. It's been a while, but I'm nearly certain I implemented O_NOFOLLOW and O_NOLINKS entirely in filesystem-independent code. So the answer should be the same for all filesystems. Scott -- Scott Rotondo Principal Engineer, Solaris Security Technologies President, Trusted Computing Group Phone/FAX: +1 408 850 3655 (Internal x68278)
2009/387 [Pathname Reparse Points]
On Fri, Jul 10, 2009 at 10:18:23AM -0700, Scott Rotondo wrote: Darren J Moffat wrote: This looks very cool but I haven't quite got my head around it completely yet. What happens if open(2) is called with O_NOFOLLOW set on one of these reparse points ? (Please answer for ZFS local access, NFS and CIFS). Since these reparse points are implemented with a special type of symlink, open() with O_NOFOLLOW should fail with such an object. On the client side a server-side reparse point behaves like a mount point, very much in the same way as mirror mounts. Locally (on the server) a reparse point is stored in a symlink, but it isn't followed, and if it were then it'd behave like a mount, just as on the client side. There's nothing quite like following a symlink here, therefore O_NOFOLLOW shouldn't apply on the client side. An option to not cross mount-points and/or an option to not trigger [mirror or referral] mounts might be nice. E.g., O_XDEV and O_XTRIGGER. Nico --
2009/387 [Pathname Reparse Points]
On Fri, Jul 10, 2009 at 10:40:04AM -0700, Garrett D'Amore wrote: I actually wonder if a different approach to this would be better -- say a per-filesystem tunable that enables parsing of symbolic links, then a simple -- *short* -- magic token that activates it. Say @@ or somesuch. (Simpler is better here.) The filesystem tunable would be available for administrators that don't want to use referrals, and have @@ (or whatever the magic token is) references already in their filesystems... The magic could actually be a special automount map, so that any app reading a symlink and traversing it on its own would still get to the right object. /ref/reparse-point-config
VRRP Update [PSARC/2009/388 FastTrack timeout 07/17/2009]
I'm submitting this fast-track for Cathy Zhou, it times out on 07/17/2009. This case depends on PSARC/2008/693. 2008/693 requested micro release binding, but no incompatible changes are introduced, and patch would be more appropriate (although no backport is planned). As such, this case both requests patch binding, and updates 2008/693 to have patch binding as well. The materials directory contains this specification (vrrp_psarc) as well as the documents listed in the References section. VRRP Update: Summary === This case describes several design issues of the original VRRP case (PSARC/2008/693 VRRP) and the proposals to address those issues. Problem area Specifically, the problems with the existing VRRP design are: 1) Incorrect false accept_mode support According to the VRRP protocol, accept_mode can be set to either true or false by an administrator over a non-address-owner VRRP virtual router. If the accept_mode is set to be false, when the VRRP virtual router becomes the master (non-backup), this virtual router must not accept packets destined to the virtual IP addresses which are configured on this router. But the router must respond to the ARP request/ND solicitations for the virtual IP addresses. The existing VRRP design described two approaches to support the false accept_mode: a. For non-link-local virtual IP addresses, add the ARP/ND cache using the SIOCSXARP/SIOCLIFSETND ioctl in order to respond to the ARP request/ND solicitations. Note that these virtual IP addresses are not brought up on the VRRP interfaces. b. For link-local virtual IP address, a new interface flag IFF_LL_NOACCEPT is introduced to mark a VNIC as non-accept mode. On receiving ioctl SIOCSLIFFLAGS request for IFF_LL_NOACCEPT, the IRE entry for the link-local address of the interface will be marked as IRE_MARK_NOACCEPT. If an ire which is looked up for a link local destination address turns out to have this flag marked, the input packets will be dropped in ip_rput_data_v6(). The above approaches do not work. Note that with approach (a), no IP address is brought up on the specific interface (in the IPv4 case), the ill of this interface will not be bound and the SIOCSXARP ioctl will simply fail. Furthermore, both approaches would drop all the unicast packets including the unicast Neighbor solicitation, which makes the Neighbor Unreachability Detection mechanism unusable. 2) Duplication of administrative interfaces and system services The administration model proposed by PSARC/2009/693 assumes that VRRP service has full management over the VRRP IP interfaces, the primary IP addresses and and the virtual IP addresses used by the specific VRRP router. The vrrpd daemon plumbs/unplumbs the VRRP interfaces and configures/unconfigures the associated IP addresses based on the current state of the VRRP router. But the design does not consider the interaction with the other existing IP interfaces configuration tools (network/physical service, ifconfig etc.), and the potential impacts of such interaction is unkown. More important, since the existing design assumes the entire control over the VRRP interface IP addresses, it makes the vrrpadm another administrative tool to configure IP addresses, which will never be as flexible as the existing tool. E.g., do we need to extend vrrpadm to configure one specific IP address to be the preferred address? Likewise, since the vrrpd internally create/destroy the special VRRP VNICs, we will lose the flexibilities provided by the existing dladm command and the feature it provides (flows, bandwidth, priority etc.). 3) No exclusive-zone support With the old VRRP PSARC case, the administrator specifies the name of the interface that will be managed by VRRP, and vrrpd would internally create and plumb a special VRRP VNIC over that interface and configure virtual IP addresses over that VNIC. This makes the VRRP support in an exclusive-zone problematic, since creating VNIC in an non-global zone is not supported. 4) No VLAN support The same design makes VRRP support over VLAN problematic as well, since the current VRRP design blindly try to create VNIC over the specified interface, and creating VNIC over an VLAN is not allowed either. Proposal Overview = - vrrpadm changes 1) Add -router to each vrrpadm subcommand Following the precedent of dladm, all the vrrpadm subcommands will contain the object of the operation - the router. For example, vrrpadm create will be changed to vrrpadm create-router, and
2009/387 [Pathname Reparse Points]
Darren J Moffat wrote: What happens if open(2) is called with O_NOFOLLOW set on one of these reparse points ? (Please answer for ZFS local access, NFS and CIFS). For a process opening a symlink on ZFS, current behaviour in the open(2) man page should be seen (open() results in -1/ELOOP). This should also be the short-term behaviour with an open done on NFS and CIFS filesystems. In the longer term (and after delivering software to be defined in future cases), the intent is to have NFSv4 and CIFS return referrals instead of making the symlinks visible to the clients. So why not just a system attribute to store the whole thing ? Particularly since it is required to store a system attribute to distinguish a reparse point from a normal symlink anyway. Archivers that slurp and spit the symlink contents will work without mods as long as they get all of the bytes, but would need more extensive modifications if our storage was in a system attribute. Also, we can get the single bit we need in ZFS now, and a 16K sysattr will not be supportable for a few more months. Also if we do end up adding BSD magic link support for the link types they have can a symlink link still have reparse data in it ? I believe other types of magic links would not be supported in the same symlink. Rob T
2009/387 [Pathname Reparse Points]
Garrett D'Amore wrote: I'm confused. Brian says that archivers Just Work with the current form, because the attributes are retained. Yet, you're saying that the attributes are not necessarily retained. Which is it? Right now, either way, you have an attribute... which I *think* means that the you need support (which may or may not be present) in the archivers. I know that some archivers in use today will not create a different bitstream for a reparse point than for a regular symlink, but I believe our intent to set the bit on restore or create means that we don't have to teach all archivers about the new bit. If any Sun-maintained archivers are aware, that's fine, but this should work with GNU tar, too. Logically, that bit is only a way for the NFS/CIFS server code to avoid having to read the symlink data to understand that it's touched a reparse point. We want this because the referral is a two-part deal - we return an it's not here error to the client first, and then respond to a followup query later. The sysattr makes an NFSv4 READDIR op able to avoid N accesses to symlink data. Rob T
2009/387 [Pathname Reparse Points]
I actually wonder if a different approach to this would be better -- say a per-filesystem tunable that enables parsing of symbolic links, then a simple -- *short* -- magic token that activates it. Say @@ or somesuch. (Simpler is better here.) The filesystem tunable would be available for administrators that don't want to use referrals, and have @@ (or whatever the magic token is) references already in their filesystems... The reason we proposed the one bit extensible attribute is that consumers like CIFS and NFS could quickly determine whether or not a symlink is a reparse point without having to look at the content. This is, as explained in the case, can be done by a single VOP_LOOKUP. Afshin
2009/387 [Pathname Reparse Points]
Nicolas Williams wrote: On Fri, Jul 10, 2009 at 10:40:04AM -0700, Garrett D'Amore wrote: I actually wonder if a different approach to this would be better -- say a per-filesystem tunable that enables parsing of symbolic links, then a simple -- *short* -- magic token that activates it. Say @@ or somesuch. (Simpler is better here.) The filesystem tunable would be available for administrators that don't want to use referrals, and have @@ (or whatever the magic token is) references already in their filesystems... The magic could actually be a special automount map, so that any app reading a symlink and traversing it on its own would still get to the right object. /ref/reparse-point-config That would be a quite elegant design, IMO. - Garrett
2009/387 [Pathname Reparse Points]
Robert Thurlow wrote: Garrett D'Amore wrote: I'm confused. Brian says that archivers Just Work with the current form, because the attributes are retained. Yet, you're saying that the attributes are not necessarily retained. Which is it? Right now, either way, you have an attribute... which I *think* means that the you need support (which may or may not be present) in the archivers. I know that some archivers in use today will not create a different bitstream for a reparse point than for a regular symlink, but I believe our intent to set the bit on restore or create means that we don't have to teach all archivers about the new bit. If any Sun-maintained archivers are aware, that's fine, but this should work with GNU tar, too. Okay, that's an important detail that I missed somewhere. (Was it in the original spec?) Logically, that bit is only a way for the NFS/CIFS server code to avoid having to read the symlink data to understand that it's touched a reparse point. We want this because the referral is a two-part deal - we return an it's not here error to the client first, and then respond to a followup query later. The sysattr makes an NFSv4 READDIR op able to avoid N accesses to symlink data. OK. -- Garrett Rob T
2009/387 [Pathname Reparse Points]
Garrett D'Amore wrote:
Robert Thurlow wrote:
Garrett D'Amore wrote:
I'm confused. Brian says that archivers Just Work with the current
form, because the attributes are retained. Yet, you're saying that
the attributes are not necessarily retained. Which is it? Right
now, either way, you have an attribute... which I *think* means that
the you need support (which may or may not be present) in the archivers.
I know that some archivers in use today will not create a different
bitstream for a reparse point than for a regular symlink, but I
believe our intent to set the bit on restore or create means that
we don't have to teach all archivers about the new bit. If any
Sun-maintained archivers are aware, that's fine, but this should
work with GNU tar, too.
Okay, that's an important detail that I missed somewhere. (Was it in
the original spec?)
Yes, it is:
fop_symlink() needs to be modified to recognize the reparse
@{REPARSE} tag and pass the appropriate attribute (i.e. reparse
system attribute) to VOP_SYMLINK to be set on the symlink.
Afshin
Logically, that bit is only a way for the NFS/CIFS server
code to avoid having to read the symlink data to understand
that it's touched a reparse point. We want this because the
referral is a two-part deal - we return an it's not here
error to the client first, and then respond to a followup
query later. The sysattr makes an NFSv4 READDIR op able to
avoid N accesses to symlink data.
OK.
-- Garrett
Rob T
2009/387 [Pathname Reparse Points]
On Fri, Jul 10, 2009 at 12:36:02PM -0700, Garrett D'Amore wrote: Nicolas Williams wrote: On Fri, Jul 10, 2009 at 10:40:04AM -0700, Garrett D'Amore wrote: I actually wonder if a different approach to this would be better -- say a per-filesystem tunable that enables parsing of symbolic links, then a simple -- *short* -- magic token that activates it. Say @@ or somesuch. (Simpler is better here.) The filesystem tunable would be available for administrators that don't want to use referrals, and have @@ (or whatever the magic token is) references already in their filesystems... The magic could actually be a special automount map, so that any app reading a symlink and traversing it on its own would still get to the right object. /ref/reparse-point-config That would be a quite elegant design, IMO. Maybe, but the key thing is that such a map need not be implemented from day 1. By just reserving and using the potential special map mountpoint the option would remain available to do this. Also, I'm not sure that apps that read symlinks should have any expectations that the contents of a symlink will be a filesystem path. Nico --
Support off-line files on SAM-QFS for Samba in Solaris [PSARC/2009/381 FastTrack timeout 07/13/2009]
Darren, I agree with Alan's proposal that the existing system extended attributes be expanded to include offline or whatever the appropriate tag could be. This would require a change to SAM-QFS to support Solaris extended attributes in at least the case of that flag (a SAM-QFS project/case, I'd guess) and modifying the interfaces introduced in PSARC/2007/315 to include the newly defined flag. This case appears to be asking to use existing interfaces of SAM-QFS to cause the Solaris provided samba to detect a condition that is causing the described customer problem, and mitigate it. The resultant FILE_ATTRIBUTE_OFFLINE within the SMB_QUERY_FILE_BASIC_INFO appears to be standard (at least in the SNIA document). I would think that advise to the PAC about modifying SAM-QFS to at least support an system extended attribute for offline, and for some unknown group to add that to the existing system extended attributes would be an appropriate response. In the mean time, I would think this case could be approved with a TCR to modify the version of Samba shipped by Sun when the architecturally appropriate interfaces (those using the existing infrastructure described in PSARC/2007/315) exist in Sun current and future HSM products. I could help add this to the general opinion, or add it as a minority opinion. == Rick On 07/ 9/09 04:33 AM, Darren J Moffat wrote: Alan.M.Wright wrote: Providing this as a temporary solution to relieve a customer problem is excellent. My disagreement is that it should be committed as a long term solution for offline support when we already have a defined system attribute mechanism that could be used to solve the problem via libc. Given the above I'm derailing this case for the purpose of writing an opinion with Advice to fund the above mentioned project and to point out the issue of adding Solaris/Sun functionality to Samba with no planned match for the in kernel CIFS server. PSARC members please are you willing to vote based on the above our would you like to see draft opinion text first. I've marked the case as waiting need vote for now. Note that this is *derail* not *deny* (though depending on the vote it could be but I doubt it). -- - 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 -
Sun4v faulted SP events extension [PSARC/2009/389 Self Review]
I am sponsoring this case for Anthony Yznaga. This case seeks Patch binding for a Solaris Update release. The case delivers extension to support Sun4v faulted SP events and is a minor extension to the existing PSARC/2008/744 case. I am filing this case as self-review and is marking it Closed Approved Automatic. If any ARC members have questions or believe that the case is above the automatic approval threshold, please let me know and I'll put a timer on it. Sun Proprietary: Need-to-Know 1. Introduction 1.1. Project/Component Working Name: Sun4v faulted SP events extension 1.2. Name of Document Author/Supplier: Anthony Yznaga 1.3. Date of This Document: June 9 2009 4. Technical Description: Exported Hardware Component NameDescriptionStability ------ spa service processorSun Private Exported InterfaceStability ----- sun4v faulted SP Events Sun Private The Event definitions themselves will be archived persistently in the FMA Event Registry. An 'ercheck' summary of the new events is included in the case directory as events_summary.html and the approved FMA portfolio information can be found here: http://wikihome.sfbay.sun.com/fma-portfolio/Wiki.jsp?page=2009.011.faultedSP 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open
