PSARC/2008/249 - Packet Interception for the MAC layer
James Carlson wrote:
> Darren Reed writes:
>> With the extension of the timer for this project to tbe 10th of December,
>> I'm updating the materials submmitted to cover changes required to
>> support the eventual filtering of WiFi packets.
>
> A few quick questions and checks:
Jim,
Thank you very much for your help and comments!
>
> 1. I assume that "net_getlifaddr" in the context of a MAC hook
> actually returns a MAC layer address, and not an IP address as the
> name "lif" might otherwise suggest. Right?
Yes, that's right. For MAC hook we're kind of reusing the same function
though there is actually no "lif" at MAC layer. :-) I'd like to hear your
suggestions on this.
>
> 2. You give the new rule processing as:
>
> [INPUT] -> L2 firewall -> "layer2" IP NAT -> "layer2" IP firewall ->
> ... -> IP NAT -> IP firewall -> { IP } -> IP firewall -> IP NAT -> ...
> -> L2 firewall -> "layer2" IP firewall -> "layer2" IP NAT -> [OUTPUT]
>
> I don't understand why the ordering of operations isn't just
> reversed on output. Assuming the input order is correct (and it
> appears to me to be right), the "L2 firewall" element should be
> the last operation before "[OUTPUT]."
It could be a useful feature to combine filtering on L2 and L3
together, or even trigger conditional IP NAT from a L2 filtering rule,
though they are not supported in the current project scope, down the
road we may want to add it, and these features require that L2 firewall
to be processed before those "layer2" IP rules.
Also, since the packet is received at MAC layer, it might be more
straight forward to do the parsing and matching from the MAC header,
as we need to parse the MAC header first anyway to locate the IP header
start. It also allows a simpler implementation in IPFilter but that
can be considered an implementation issue anyway.
Would the above make sense?
>
> 3. We're defining these bits of syntax ourselves, and we're expecting
> that administrators are going to rely on them for the security of
> their systems. Given that, is "Volatile" the right classification
> for the new "family ether" and "layer2" configuration keywords?
We'll think more about this.
>
> 4. Why is hpe_hdrinfo "void *" rather than "hook_pkt_info_t *"?
For MAC layer, it is actually "mac_header_info_t *".
> Void
> pointers are mildly evil, as they prevent the compiler and lint
> from doing their type-checking jobs. What else would hpe_hdrinfo
> point to?
The major reason for using "void *" here, is that hook_pkt_event_t
is a quite general structure that works with all protocols, thus I
feel it is probably not appropriate to use types that specific to
one protocol, e.g. mac_header_info_t is specific to MAC. Also it
could point to other data structure for protocol other than MAC
layer, though there's not such need right now.
>
> (One very small code review nit: as an argument in a function
> definition [dls_devnet_*name2*name], 'const size_t' doesn't do
> anything that 'size_t' alone wouldn't do.)
>
Thank you, will fix.
Regards,
Zhijun
mailwrapper (PSARC/2008/759)
Ceri Davies wrote: > On Wed, Dec 10, 2008 at 11:28:16AM +1100, Darren Reed wrote: >> John, >> >> What's the plan for mailx(1) use of of mailwrapper? >> Is it intended for mailx(1) to remain as a frontend to sendmail >> (only) or will it also use mailwrapper(1M)? >> >> If it's going to use mailwrapper(1M), then this case looks >> a bit incomplete as mailx(1) seems to suggest a few bits >> of its functionality are tied to sendmail... > > General usage is covered by an entry for "mail" in mailer.conf. > > The "conv" functionality, while alluding to a (undocumented) -U option to > sendmail(1M), is implemented internally to mailx(1). That sounds like a man page bug for mailx(1). > I can see -h, -m/metoo and possibly -v/verbose being an issue if a user > decides to switch out sendmail; would warnings in the manuals cover > this? What are you proposing be added? I suppose the important point here is that if a new mail application is installed that does something strange with -h/-m/-v then the unknowning user may get behaviour that wasn't intended. But in the very least, postfix also supports -v (but not -h/-m, it seems.) On one side, you might expect the developer of the new MTA to be aware of this and develop their CLI options to fit in. Looking at the man page for mailwrapper on NetBSD, that is the suggested outcome where other MTAs are written to fit the calling conventions of MUAs that expect sendmail to be there. The experiences thus far would suggest that at least this has happened, if it has been the case that there have been no reported interoperability issues here in the last decade (I'm rounding up your 9 years :) Thinking about it, it seems like the MTA/MUA history has proceeded along the right lines without anyone actually having laid down any rules because all MUAs are written to use sendmail and all MTAs are written to be invoked like sendmail. The question is, should we formalise this any further? Should, for example, the man page for mailwrapper explicitly reference sendmail for its CLI options? (The man page I'm looking at right now doesn't quite go that far in defining what the interfaces are.) Darren
contract signatures for 2008/688 Sun Cluster TCP/IP Hooks Update
I agree, too. Zhaozhou Li Solaris Networking B R Clouse ??: > > I agree. > > -Burt Clouse > Solaris Cluster > > > James Carlson wrote: >> In order to finish out this case, I'll need archived "signatures" from >> each of the two managers on the 'to' line above. A "signature" is >> just an email message saying "I agree," and the "reply-to" for this >> message has been set to psarc-ext at sun.com, which is where they need to >> go for archiving. >> >> A copy of the contract (for your review) is below. >> >> >> >> @(#)contract 1.8 @(#) /shared/sac/arc/ARC-Templates/contract [1.8 >> 06/12/06] >> >> CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES >> >> 0. Number: PSARC/2008/688-01 >> >> 1. This contract is between >> a SUPPLIER of INTERFACES and >> a CONSUMER of those INTERFACES, >> both of whom are entities within Sun Microsystems, Incorporated. >> >> 2. The SUPPLIER (definer and/or implementor) is identified by the >> following: >> Product or Bundle: Solaris >> Consolidation: OS/Net >> Department or Group: Networking >> Bugster Product/Category/SubCategory: kernel/tcp-ip >> Responsible Manager: Zhaozhou Li >> >> 3. The CONSUMER is identified by the following: >> Product or Bundle: Sun Cluster >> Consolidation: Sun Cluster >> Department or Group: Sun Cluster >> Bugster Product/Category/SubCategory: suncluster/suncluster/networking >> Responsible Manager: Burt Clouse >> >> 4. The INTERFACES are: >> >> cl_inet_connect2 Project Private >> cl_inet_isclusterwide Project Private >> cl_inet_ipident Project Private >> cl_inet_getspi Project Private >> cl_inet_checkspi Project Private >> cl_inet_deletespi Project Private >> cl_inet_idlesa Project Private >> cl_inet_listen Project Private >> cl_inet_unlisten Project Private >> cl_inet_disconnect Project Private >> cl_tcp_walk_list Project Private >> cl_inet_bind Project Private >> cl_inet_unbind Project Private >> >> All are described in PSARC 2008/688. >> >> 5. The ARC controlling these INTERFACES is: PSARC >> >> 6. The CASE describing (Exporting) these INTERFACES is: 2008/688 >> >> 7. The following SPECIAL ARRANGEMENTS are made which modify the rules >> imposed by the stability levels listed in section 4 above: >> >> _Y_ 7c. Although the stability level doesn't normally allow it, >> CONSUMER will >> import INTERFACES from a separate consolidation. >> >> _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any >> portion of the INTERFACES, SUPPLIER will notify CONSUMER of the >> proposed new version, no later than the application for ARC >> approval of the new version. >> If SUPPLIER and CONSUMER are contained in the same consolidation, >> they have the option of arranging for simultaneous conversion >> to the new interfaces. If this is not possible, or if they are >> not in the same consolidation, then SUPPLIER will either make best >> effort to work with CONSUMER so that CONSUMER can detect which >> version of INTERFACES is being supplied, or else SUPPLIER will >> make best effort to supply both old and new versions of >> INTERFACES. >> If SUPPLIER cannot make both versions of INTERFACES available, >> and SUPPLIER and CONSUMER cannot devise a method whereby >> CONSUMER can detect which version of INTERFACES is being >> supplied, and the old version of CONSUMER will not run with the >> new version of SUPPLIER, then either the EOL process must be >> followed by SUPPLIER, or else a major release of SUPPLIER will >> be required, or the change will not be allowed. >> >> 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make >> best effort to accommodate such changes, which shall then be >> treated in accordance with paragraph 7 above. >> >> 9. Notwithstanding paragraphs 7 and 8, a change to any portion >> of the INTERFACES shall be regarded as a completely new set of >> INTERFACES which require both ARC approval and execution of >> a new contract. >> >> 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be >> handled as follows: >> >> Interfaces will be changed only on Minor release boundaries, >> except for mutually agreed-on bug fixes. Changes can be >> requested by either party, with the understanding that the >> SUPPLIER can request resources from CONSUMER to implement >> the changes. >> >> 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as >> follows: >> >> CONSUMER will perform regression tests and file bugs as >> appropriate. >> >> 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as >> follows: >> >> The materials for this case are the only documentation supplied. >> >> 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be >> tested as follows: >> >> CONSUMER shall perform integration testing. >> >> 14. SUPPLIER and CONSUMER agree that this contract can be terminated as >> follows: >> >> By mutual consent. >> >> 15. This contract is not valid until "signed" via agreement from the >> SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by >>
questions regarding APIC configuration. thanks (case 11336173)
Hi experts, I would like consult you some questions regarding APIC. # mdb -k Loading modules: [ unix krtld genunix specfs dtrace cpu.AuthenticAMD.15 uppc pcplusmp ufs ip hook neti sctp arp usba fcp fctl nca lofs zfs random nfs sppp crypto ptm logindmux md cpc fcip ipc ] > ::interrupts IRQ Vector IPL Bus Type CPU Share APIC/INT# ISR(s) 10x41 5 ISA Fixed 3 1 0x0/0x1 i8042_intr 30xb1 12 ISA Fixed 2 1 0x0/0x3 asyintr 40xb0 12 ISA Fixed 2 1 0x0/0x4 asyintr 60x43 5 ISA Fixed 1 1 0x0/0x6 fdc_intr 90x81 9 PCI Fixed 1 1 0x0/0x9 acpi_wrapper_isr 12 0x42 5 ISA Fixed 3 1 0x0/0xc i8042_intr 16 0x61 6 PCI Fixed 3 1 0x0/0x10 iprb_intr 20 0x20 1 PCI Fixed 0 1 0x0/0x14 ehci_intr 21 0x21 1 PCI Fixed 1 1 0x0/0x15 ohci_intr 28 0x60 6 PCI Fixed 2 2 0x2/0x0 adpu320_intr, bge_intr 29 0x40 6 PCI Fixed 2 2 0x2/0x1 bge_intr, adpu320_intr 160 0xa0 0 IPI ALL 0 - poke_cpu 192 0xc0 13IPI ALL 1 - xc_serv 208 0xd0 14IPI ALL 1 - kcpc_hw_overflow_intr 209 0xd1 14IPI ALL 1 - cbe_fire 210 0xd3 14IPI ALL 1 - cbe_fire 240 0xe0 15IPI ALL 1 - xc_serv 241 0xe1 15IPI ALL 1 - apic_error_intr From OS, can we config APIC value ? for example, which command or tools or configuration file can be used to change APIC value ? If APIC can be changed, do we support this operation after it is changed ? Thank you very much. Best Regards chunhuan
sun4v Platform Independent CPU/Mem FMA events [PSARC/2008/744 FastTrack timeout 12/09/2008]
This case was approved during the December 10th PSARC meeting. -tim
PSARC/2008/249 - Packet Interception for the MAC layer
James Carlson wrote:
>>> 2. You give the new rule processing as:
>>>
> [...]
>
>>> I don't understand why the ordering of operations isn't just
>>> reversed on output. Assuming the input order is correct (and it
>>> appears to me to be right), the "L2 firewall" element should be
>>> the last operation before "[OUTPUT]."
>>>
>> It could be a useful feature to combine filtering on L2 and L3
>> together, or even trigger conditional IP NAT from a L2 filtering rule,
>> though they are not supported in the current project scope, down the
>> road we may want to add it, and these features require that L2 firewall
>> to be processed before those "layer2" IP rules.
>>
>> Also, since the packet is received at MAC layer, it might be more
>> straight forward to do the parsing and matching from the MAC header,
>> as we need to parse the MAC header first anyway to locate the IP header
>> start. It also allows a simpler implementation in IPFilter but that
>> can be considered an implementation issue anyway.
>>
>> Would the above make sense?
>>
>
> I'm not sure, but I don't think any of it answers the actual question
> I had. You currently have this:
>
> [INPUT] -> L2 firewall -> "layer2" IP NAT -> "layer2" IP firewall ->
> ... -> IP NAT -> IP firewall -> { IP } -> IP firewall -> IP NAT -> ...
> -> L2 firewall -> "layer2" IP firewall -> "layer2" IP NAT -> [OUTPUT]
>
> But that's not entirely symmetric, and I don't see why. I would have
> expected it to be:
>
> [INPUT] -> L2 firewall -> "layer2" IP NAT -> "layer2" IP firewall ->
> ... -> IP NAT -> IP firewall -> { IP } -> IP firewall -> IP NAT -> ...
> -> "layer2" IP firewall -> "layer2" IP NAT -> L2 firewall -> [OUTPUT]
>
> That would be symmetric processing: we go through steps A through E on
> input, and then E' through A' on output. That's easy to understand.
>
> I don't understand doing A-E on input, and then E', D', A', C', B' on
> output, which is what you've documented. Is there a reason for this?
>
> (This is my only real sticking point right now.
Jim,
Yes I know what you're saying. :-)
I agree that it makes sense for the processing to be entirely symmetric.
The problem with that, as I understand, is it will remove future chances
to combine L2 + L3 filtering together, or trigger L3 NAT conditionally
from L2 filtering rules.
(forgive me about the invented keywords below as it is just an example,
and won't be provided in this project)
For input, we might want to do something like below in the future:
#pass in family ether from 11:22:33:44:55:55 to any l2-head 100
#pass in proto tcp from any to any l2-group 100 layer2
For output, we might want to do something similar:
#pass out family ether from 66:55:44:33:22:11 to any l2-head 200
#pass out proto tcp from any to any l2-group 200 layer2
(the same for combining L2 filtering + "layer2" L3 NAT)
To do this, we need the L2 firewall to be processed earlier
than "layer2" IP firewall (and "layer2" IP NAT), for
both INPUT and OUTPUT, as otherwise we don't know whether
a "layer2" IP firewall/NAT rule should be processed or not
if we do E -> D -> C -> B -> A for output, as the rules
can be conditional which depend on the L2 firewall rules,
which haven't be processed at that time.
Is there actual problems in your mind that could be caused by
the current "not entirely symmetric" approach?
Thank you,
Zhijun
--
#mdb -K
[0]> eri.prc.sun.com::walk staff s|::print staff_t s_name|
::grep .== zhijun |::eval :c
-- next part --
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081211/b99971a5/attachment.html>
sun4v Platform Independent CPU/Mem FMA events [PSARC/2008/744 FastTrack timeout 12/09/2008]
Scott Davenport writes: > Thankssince the timer has expired and Tim's in Germany, would you be > able to mark the case as approved? Tim got to it before I could; he's in Germany, but I'm in Massachusetts, and 10PM is pretty late. > Also, the event registry (in snapshot form) is available publicly > via http://www.opensolaris.org/os/project/events-registry/. But don't > disagree that there can be some process improvement here. OK; thanks, that helps. The link provided with the case materials was a SWAN-only link. -- James Carlson, Solaris Networking 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
"Cluster" Brand Zone Interfaces [PSARC/2008/747 FastTrack timeout 12/10/2008]
This fast-track has time out with no objections. The contract was signed by both managers, so I am marking it closed approved. Thanks, Jerry
OpenSolaris ARC Agenda - December 16 17, 2008
http://www.opensolaris.org/os/community/arc/announcements/ OpenSolaris ARC Agenda TELECONFERENCE NUMBERS: (866)545-5223 (Within US) (215) 446-3661 (International) ACCESS CODE 939-55-86 Times are US/Pacific Timezone ARC meetings are recorded. TUESDAY December 16, 2008 Open Meeting Canceled. There aren't any open fast-tracks or open agenda items as of 12/11/2008.(Please refer to closed session Agenda for closed meeting details.) WEDNESDAY December 17, 2008 10:00-10:10 Open ARC Business Case (Timeout) Exposure Title (Last Updated 12/11/2008) 2008/249 (12/10/08) open Packet interception for the MAC layer 2008/714 (11/25/08) open Dante: A Socks server and client implementation 2008/737 (12/08/08) open CIFS Client Message Signing 2008/752 (12/11/08) open BOOST C++ Framework 2008/755 (12/17/08) open ddi/ssoft/state(9F) and ddi/isoft/state(9F) 2008/756 (12/15/08) open Integrate unrar 2008/757 (12/16/08) open SPARC support for AST graphics 2008/759 (12/17/08) open mailwrapper 2008/760 (12/12/08) open Boot configuration Service 2008/762 (12/17/08) open IB Support for Relaxed Ordering 10:10-10:55 Open Inception: Solaris Bridging (2008/055) This project provides Ethernet datalink-layer bridge functionality for Solaris and OpenSolaris. Submitter: James Carlson Owner: James Carlson Exposure: open -- next part -- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081211/24aaeba8/attachment.html>
PSARC/2008/249 - Packet Interception for the MAC layer
Zhijun Fu wrote: > For input, we might want to do something like below in the future: > > #pass in family ether from 11:22:33:44:55:55 to any l2-head 100 > #pass in proto tcp from any to any l2-group 100 layer2 > > For output, we might want to do something similar: > > #pass out family ether from 66:55:44:33:22:11 to any l2-head 200 > #pass out proto tcp from any to any l2-group 200 layer2 > > (the same for combining L2 filtering + "layer2" L3 NAT) > > To do this, we need the L2 firewall to be processed earlier > than "layer2" IP firewall (and "layer2" IP NAT), for > both INPUT and OUTPUT, as otherwise we don't know whether > a "layer2" IP firewall/NAT rule should be processed or not > if we do E -> D -> C -> B -> A for output, as the rules > can be conditional which depend on the L2 firewall rules, > which haven't be processed at that time. One way to think about this is that what you have as the rule with l2-head isn't a traditional firewall rule, but that it instead is a classification rule whose result is to tag/label the packet for further processing. Other rules can then be written which use the tag/label. In that case clearly the classification has to happen before its use. But I don't see l2-head and l2-group in the current case, thus to avoid confusing the users couldn't we simplify the current description to be symmetric? Erik
PSARC/2008/249 - Packet Interception for the MAC layer
Erik Nordmark writes: > Zhijun Fu wrote: > > To do this, we need the L2 firewall to be processed earlier > > than "layer2" IP firewall (and "layer2" IP NAT), for > > both INPUT and OUTPUT, as otherwise we don't know whether > > a "layer2" IP firewall/NAT rule should be processed or not > > if we do E -> D -> C -> B -> A for output, as the rules > > can be conditional which depend on the L2 firewall rules, > > which haven't be processed at that time. > > One way to think about this is that what you have as the rule with > l2-head isn't a traditional firewall rule, but that it instead is a > classification rule whose result is to tag/label the packet for further > processing. > Other rules can then be written which use the tag/label. Yes. And I think there's probably a more flexible way to do this using the existing "head" logic in IP filter, and just making the internal logic smarter when dealing with packets that may have either L2 or L3 origin. > In that case clearly the classification has to happen before its use. > > But I don't see l2-head and l2-group in the current case, thus to avoid > confusing the users couldn't we simplify the current description to be > symmetric? I think the reason the submitter wants to do this is to retain the option of doing the same "l2-head" thing as was originally proposed, just at some later date. As for the current proposal, I think symmetric is much easier to understand. It would be really strange to find that (for instance) an L2 firewall rule precluding sending packets to a particular MAC destination could be overridden by an L2 IP firewall or IP NAT rule that rewrites the IP destination, but that the input side blocks the traffic as expected. -- James Carlson, Solaris Networking 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
mailwrapper (PSARC/2008/759)
John Beck wrote: > The programmatic interface to sendmail involves exec'ing a program > named /usr/lib/sendmail (or, outside Solaris, /usr/sbin/sendmail). > Administrators wishing to use an alternate MTA have to replace that > binary, which generally doesn't play all that well with packaging > and upgrade (sendmail isn't an editable file; multiple packages > delivering the same file is considered a no-no, etc.,). > > * Solution > > The common BSD distributions (FreeBSD, NetBSD, OpenBSD) include a > program called "mailwrapper" which allows for easy, packaging-safe > selection of the shell-command level interface to the default system > MTA. /usr/sbin/sendmail is a symlink to the mailwrapper binary, and > the "real" sendmail is installed somewhere else (on the *BSDs, > this is /usr/libexec/sendmail/sendmail). > > A default mailer.conf is delivered so that mailwrapper exec's > through to the real sendmail binary; an admin wishing to select > an alternate MTA will install it wherever they like (/opt, /usr/pkg, > etc.) and then edit the mailer.conf file as appropriate for the > new MTA. What is the advantage of mailwrapper versus merely moving the sendmail binary to somewhere else and placing default symlinks at /usr/sbin/sendmail and usr/lib/sendmail pointing to it, which symlinks can be replaced as required by the installer of an alternate MTA? - Jeremy Harris
mailwrapper (PSARC/2008/759)
On Thu, Dec 11, 2008 at 08:32:48PM +, Jeremy Harris wrote: > What is the advantage of mailwrapper versus merely moving the > sendmail binary to somewhere else and placing default symlinks > at /usr/sbin/sendmail and usr/lib/sendmail pointing to it, which > symlinks can be replaced as required by the installer of an alternate > MTA? Symlinks do not a good configuration interface make.
ddi_ssoft_state(9F) and ddi_isoft_state(9F) [PSARC/2008/755 FastTrack timeout 12/17/2008]
I have reached closure with Garret and Ed, the updated spec is below. To summarize the changes: rename: ddi_ssoft_state* -> ddi_soft_state_bystr* drop: ddi_isoft_state* args: ddi_soft_state_bystr_init: rename: hash_sz -> n_items The timer has been reset to 12/17/2008. Thanks -Chris -- next part -- An embedded and charset-unspecified text was scrubbed... Name: soft_state.fasttrack.txt URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081211/0a460917/attachment.txt>
2008/757 SPARC support for AST graphics
An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081211/a8b7023d/attachment.html>
Cfgadm SCSI-Plugin MPxIO Support [PSARC/2008/764 Self Review]
I am sponsoring this case as a fast-track for Hyon Kim. No interfaces are introduced or modified but the team desires to record this information. The project team believes this case qualifies for self-review with automatic approval, so I've introduced it as such. Patch/micro release binding is requested. -- Cfgadm SCSI plugin support on a MPxIO enabled controller 1. Introduction 1.1. Project/Component Working Name: Cfgadm SCSI plugin support on an MPxIO enabled controller 1.2. Name of Document Author/Supplier: Author: Hyon Kim 1.3 Date of This Document: Dec 1, 2008 4. Technical Description 4.1 Background The cfgadm SCSI plugin checks only the existence and state of devinfo nodes when probing a SCSI controller apid for its child thus fails to report pathinfo based configuration on a MPxIO enabled SCSI controller. Currently mpt(7D) driver supports MPxIO and CR 6569367 addresses the missing cfgadm apids once an mpt based SAS controller is enabled with MPxIO. This fasttrack proposes updates to the SCSI plugin to make it recognize MPxIO enabled controller by probing pathinfo nodes and report pathinfo associated apids. The type field of the apid carries path indication as shown in the example below. This fasttrack doesn't introduce any change to the existing cfgadm/libcfgadm interfaces. Note that this proposal affects only the SCSI devices that are connected to an MPxIO enabled SCSI controller and are supported by scsi_vhci(7D) driver. 4.2 Proposed Solution 4.2.1 Listing operation With the proposed updates, the cfgadm SCSI plugin will construct pathinfo associated apids with the unit-address of the pathinfo nodes when probing an MPxIO enabled controller. The unit address typically contains target and logical unit number(LUN) information and uniquely identifies a device on a SCSI controller. The following cfgadm output shows MPxIO enabled mpt.7D based controller and its child apids. The disk and tape devices that are connected on controller c1 are configured as scsi_vhci.7D child devices so its dynamic component of the apids consists of the unit address. The ses and smp target devices still has /dev link based dynamic component which is constructed through the existing SCSI plugin implementation. The type field will indicates if an apid is configured as a path to a device through suffix 'path'. # cfgadm -la Ap_Id Type Receptacle Occupant Condition c1 scsi-sas connectedconfigured unknown c1::0,0disk-pathconnectedconfigured unknown c1::1,0disk-pathconnectedconfigured unknown c1::2,0disk-pathconnectedconfigured unknown c1::3,0disk-pathconnectedconfigured unknown c1::4,0disk-pathconnectedconfigured unknown c1::5,0disk-pathconnectedconfigured unknown c1::6,0disk-pathconnectedconfigured unknown c1::7,0disk-pathconnectedconfigured unknown c1::8,0disk-pathconnectedconfigured unknown c1::9,0disk-pathconnectedconfigured unknown c1::a,0tape-pathconnectedconfigured unknown c1::es/ses1ESI connectedconfigured unknown c1::smp/expd0 smp connectedconfigured unknown Without MPxIO enabled on c1, the apid for c1::0,0 and c1::a,0 would be c1::dsk/c1t0d0 disk connectedconfigured unknown c1::rmt/1 tape connectedconfigured unknown Note that apid c1 has type scsi-sas. With the fix of CR 6762621 and associated mpt.7D change of the SCSI plugin will append the initiator interconnect type as defined in uts/common/sys/scsi/impl/services.h for non SPI SCSI controller apids. The controller type will remain same whether MPxIO is enabled on the controller or not. The 'scsi-bus' type will be used for SPI controllers as it does today. In order to help the administrator map the pathinfo related apid with an associated scsi_vhci client device, the Information field will show the /dev link of the client devices as below. # cfgadm -lav c1::0,0 Ap_Id Receptacle Occupant Condition Information When Type Busy Phys_Id c1::0,0connectedconfigured unknownClient Device: /dev/dsk/c5t5000C5000B1F49DBd0s0(sd10) unavailable disk-path n /devices/pci at 0,0/pci10de,375 at f/pci1000,3150 at 0:scsi::sd17 at 0,0 # cfgadm -lav c1::a,0 Ap_Id Recept
2008/757 SPARC support for AST graphics
Eric Sultan wrote: > The project team agrees that quiesce and suspend/resume should be > supported. > > Solaris 10 deliveries will include support for DDI_SUSPEND and DDI_RESUME. > > Post-Solaris 10 deliveries will also include support for quiesce(9e). > In the initial deliveries, the quiesce vector in the dev_ops struct > will be set to ddi_quiesce_not_supported if the target OS doesn't yet > have any quiesce users. When the Fast Reboot team delivers code that > uses quiesce, the ast driver will replace that vector with one to a > device-specific quiesce entry point. I'm happy with this response. Note that on x86, there are already quiesce() users. So on x86 at least, quiesce should be supported on Nevada from the initial point of integration. (As an aside, I'm not sure there is any point in doing DDI_SUSPEND/RESUME on Solaris 10. None of the SPARC platforms in question can SUSPEND/RESUME -- or at least I don't think they can -- and x86 SUSPEND/RESUME is only supported on Solaris Nevada/OpenSolaris. So you might have a difficult time verifying suspend/resume on S10.) -- Garrett > > -- Eric > > > > > Sherry Moore wrote: >> quiesce(9E) is a newly (since build 100) added dev_ops entry point >> http://docs.sun.com/app/docs/doc/819-2255/quiesce-9e?l=en&a=view >> >> The Fast Reboot team would like the SPARC AST project team to state >> in the final case material >> >> 1. that quiesce(9E) will not be implemented at initial integration >>and why. >> >> 2. their commitment to implement quiesce(9E) when SPARC Fast Reboot >>project is in progress. >> >> Thanks, >> Sherry >> >> On Wed, Dec 10, 2008 at 10:28:56AM -0800, Garrett D'Amore wrote: >> >>> At PSARC today, this was let run, because of the question of quiesce(9e) >>> support. PSARC would like to see either the project team agree to >>> implement quiesce(9e) or a written statement from the Fast Reboot team >>> clarifying that quiesce() is not needed for this project. >>> >>> (Note that while I understand the project title indicates SPARC, earlier >>> discussion has revealed that this project also shares code with x86. I >>> personally believe the quiesce question is more germane to x86 at the >>> moment, but I'm not sure if that is tantamount to granting a blanket waiver >>> for SPARC drivers.) >>> >>> The same questions can also be made of DDI_SUSPEND and DDI_RESUME, though I >>> perceive that there is less urgency here (given that this is intended for >>> server products). >>> >>> As a final personal note, I expect that if the project team simply agrees >>> to implement both suspend/resume and quiesce, that this case will be >>> approved with no further objections. >>> >>>- -Garrett >>> >> >> >
2008/757 SPARC support for AST graphics
I'd not realized that DDI_SUSPEND/DDI_RESUME was no longer a factor in Solaris 10. I'll look into that, and am prepared to be surprised. Still, we like our source code to be as alike as possible across OS versions, so the team would deliver it into Solaris 10 anyway. The x86 support for ast won't use the SPARC kernel device driver, nor an x86 kernel driver, so the quiesce question is not a factor for ast on x86. At least, not as a part of this project. -- Eric Garrett D'Amore wrote: > Eric Sultan wrote: >> The project team agrees that quiesce and suspend/resume should be >> supported. >> >> Solaris 10 deliveries will include support for DDI_SUSPEND and >> DDI_RESUME. >> >> Post-Solaris 10 deliveries will also include support for >> quiesce(9e). In the initial deliveries, the quiesce vector in the >> dev_ops struct will be set to ddi_quiesce_not_supported if the target >> OS doesn't yet have any quiesce users. When the Fast Reboot team >> delivers code that uses quiesce, the ast driver will replace that >> vector with one to a device-specific quiesce entry point. > > I'm happy with this response. Note that on x86, there are already > quiesce() users. So on x86 at least, quiesce should be supported on > Nevada from the initial point of integration. > > (As an aside, I'm not sure there is any point in doing > DDI_SUSPEND/RESUME on Solaris 10. None of the SPARC platforms in > question can SUSPEND/RESUME -- or at least I don't think they can -- > and x86 SUSPEND/RESUME is only supported on Solaris > Nevada/OpenSolaris. So you might have a difficult time verifying > suspend/resume on S10.) > >-- Garrett >> >> -- Eric >> >> >> >> >> Sherry Moore wrote: >>> quiesce(9E) is a newly (since build 100) added dev_ops entry point >>> http://docs.sun.com/app/docs/doc/819-2255/quiesce-9e?l=en&a=view >>> >>> The Fast Reboot team would like the SPARC AST project team to state >>> in the final case material >>> >>> 1. that quiesce(9E) will not be implemented at initial integration >>>and why. >>> >>> 2. their commitment to implement quiesce(9E) when SPARC Fast Reboot >>>project is in progress. >>> >>> Thanks, >>> Sherry >>> >>> On Wed, Dec 10, 2008 at 10:28:56AM -0800, Garrett D'Amore wrote: >>> At PSARC today, this was let run, because of the question of quiesce(9e) support. PSARC would like to see either the project team agree to implement quiesce(9e) or a written statement from the Fast Reboot team clarifying that quiesce() is not needed for this project. (Note that while I understand the project title indicates SPARC, earlier discussion has revealed that this project also shares code with x86. I personally believe the quiesce question is more germane to x86 at the moment, but I'm not sure if that is tantamount to granting a blanket waiver for SPARC drivers.) The same questions can also be made of DDI_SUSPEND and DDI_RESUME, though I perceive that there is less urgency here (given that this is intended for server products). As a final personal note, I expect that if the project team simply agrees to implement both suspend/resume and quiesce, that this case will be approved with no further objections. - -Garrett >>> >>> >> >
umountall -Z [PSARC/2008/765 FastTrack timeout 12/18/2008]
I'm sponsoring this case for Pavel Filipensky to add the '-Z' option to umountall(1M). This case times out on 12/18/2008. Micro/patch binding is requested for this case. Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: umountall -Z 1.2. Name of Document Author/Supplier: Author: Pavel Filipensky 1.3 Date of This Document: 11 December, 2008 4. Technical Description This case proposes two changes: 1) It introduces a new command line option, -Z, to umountall(1M). When the umountall(1M) command is run in the global zone, this option applies the unmounting action(s) only to the file systems mounted in non-global zones. The use of -Z option in non-global zones will have no effect. 2) The default behavior of umountall(1M) is changed to limit the unmounting action(s) to the current zone. Rationale for limiting the default scope to the current zone: Currently, running umountall(1M) in the global zone unmounts file systems from the global zone and from non-global zones as well. This is causing following bugs: 6502014 NFS mounts in non-global zones are unmounted if NFS is restarted in the global zone 6512906 Autofs mounts in non-global zones are unmounted when autofs is restarted in the global zone 6777323 smb mounts in non-global zones are unmounted when smb/client is restarted in the global zone Limiting the default scope of umountall(1M) to the current zone will fix the bugs above. Rationale for adding the new -Z option: The -Z option will be used in the stop method of svc:/system/zones:default. This will take care of the case when we try to stop zones and some of them fail to shut down. It is better to try to unmount the filesystems mounted in them to free resources on the servers. There are no side effects of using -Z option on other suboptions to umountall(1). Using -Z never changes the behaviour of other suboptions, -Z only changes their scope. The webrev for these changes is available here: http://cr.opensolaris.org/~pavelf/6779275 Related CR: 6779275 umountall(1M) -Z ... limit unmounting action(s) to the non-global zones EXPORTED INTERFACES umountall(1M) optionStability Level -Z Committed DOCUMENTATION IMPACT (See 6780521) manpage umountall(1M) changes: 1. a new -Z option 2. change in the default behavior Changes are as follows: SYNOPSIS mountall [-F FSType] [-l | -r] [file_system_table] umountall [-k] [-s] [-F FSType] [-l | -r] [-n] [-Z] + umountall [-k] [-s] [-h host] [-n] [-Z]+ [...] umountall causes all mounted file systems in the current + zone except root, /usr, /var, /var/adm, /var/run, /proc, and + /dev/fd to be unmounted. If the FSType is specified, moun- tall and umountall limit their actions to the FSType speci- [...] -s Do not perform the umount operation in parallel. -Z Apply the action(s) only to the file systems + mounted in non-global zones. By default, umoun- + tall unmounts only file systems mounted in the + current zone. Has no effect if used in a non- + global zone. + FILES [...] 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
umountall -Z [PSARC/2008/765 FastTrack timeout 12/18/2008]
On Thu, Dec 11, 2008 at 10:24 PM, wrote: > > I'm sponsoring this case for Pavel Filipensky to add the '-Z' option to > umountall(1M). This case times out on 12/18/2008. > > Micro/patch binding is requested for this case. > > > Template Version: @(#)sac_nextcase %I% %G% SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction >1.1. Project/Component Working Name: > umountall -Z >1.2. Name of Document Author/Supplier: > Author: Pavel Filipensky >1.3 Date of This Document: >11 December, 2008 > 4. Technical Description > > This case proposes two changes: > > 1) It introduces a new command line option, -Z, to umountall(1M). When > the umountall(1M) command is run in the global zone, this option > applies the unmounting action(s) only to the file systems mounted in > non-global zones. The use of -Z option in non-global zones will > have no effect. To clarify, what happens if I run umountall -Z in a non-global zone? Does it ignore the -Z flag and run umountall anyway? Or does it not unmount anything? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
PowerMan 2.3 [LSARC/2008/734 FastTrack timeout 12/4/2008]
Without further comment, this case is closed approved as of yesterday, 12/10. -tdc On Dec 5, 2008, at 4:05 PM, Tom Childers wrote: > Bruce has provided the interface info for PowerMan, and I've updated > the one-pager. The relevant section now reads as follows: > > 4.0 Interfaces > (see http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ > f > or details) > 4.1 Exported Interfaces > > Interface Name Classification Comments > --- --- > --- > /usr/bin/powerman Volatileclient to power on/off > nodes > /usr/bin/pm (same) > > /usr/sbin/powermand Volatilepower control & > monitoring daemon > > /usr/sbin/plmpowerVolatilehelper program which > enables > communication with > insteon/x10 > devices. powermand runs > interactively with this > helper > man pages Volatile >/usr/share/man/man1/powerman.1 >/usr/share/man/man5/powerman.conf.5 >/usr/share/man/man5/powerman.dev.5 >/usr/share/man/man7/powerman-devices.7 >/usr/share/man/man8/powermand.8 > > 4.2 Imported Interfaces > Interface Name Classification Comments > --- > -- > SUNWlibmsCommitted > /usr/lib/libm.so2 > Math & Microtasking > Libraries > > > I'm extending the timer to Wednesday, December 10th. Please respond > with any additional issues or comments by then. > -tdc > > > On Dec 1, 2008, at 9:26 AM, James Carlson wrote: > >> Bruce Rothermal writes: >>> Lets see if I can explain this better and you all can let me know >>> how >>> much of this to put in the questionare. >>> >>> Powerman consists of a client and server process for the purpose of >>> consolidating power management (turn systems on and off as found >>> in a >>> lab environment or remote unmanned dark equipment rooms). A user >>> would >> [...] >> >> That explains what it does, but not what the interfaces are, which >> was >> the previous question: >> >>> On Nov 26, 2008, at 10:14 AM, James Carlson wrote: >>> Danek Duvall writes: > So in all of this, there's no description of what powerman > actually > *is*. It centralizes control of power control units, often used in a lab, much in the way conserver centralizes console servers. > Or what the interfaces are. Good point. >> >> The interfaces provided by this project are empty. Worse still, the >> project (as documented) claims to "import" an interface called >> "Powerman," but it can't do that as there's no other project (ARC >> case) that exports it ... this is the project that *defines* it, so >> it >> can't import it. >> >> Your fast-track sponsor should have helped with this part. To give >> you some help here (rather than playing fetch-a-rock), here's a >> _guess_ at the sorts of interfaces this project might be exporting: >> >> InterfaceStability Comments >> -- >> /usr/bin/powermanCommitted binary location >> powerman Volatilecommand line arguments and output >> /usr/bin/pm Committed symlink to `powerman' >> /etc/powerman/ Committed directory >> /etc/powerman/powerman.conf >> Committed file location >> powerman.confUnstablefile syntax >> *.devProject Private control files in /etc/powerman/ >> svc:/network/powermanCommitted SMF FMRI for server >> /usr/lib/powermand Project Private daemon >> /usr/lib/httppower Project Private connector for HTTP-based PDUs >> /usr/lib/plmpowerProject Private connector for Insteon/X10+PLM 2412S >> /var/run/powerman/ Project Private local state storage >> >> (Guessing based by what I see in SourceForge.) >> >> The imports would likely be the protocols used by those PDUs, and I'm >> not sure how to classify them. They're probably Unstable. >> >> -- >> James Carlson, Solaris Networking > > >> 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/757 SPARC support for AST graphics
Eric Sultan wrote: > I'd not realized that DDI_SUSPEND/DDI_RESUME was no longer a factor in > Solaris 10. I'll look into that, and am prepared to be surprised. > Still, we like our source code to be as alike as possible across OS > versions, so the team would deliver it into Solaris 10 anyway. Sounds reasonable. ;-) On S10, SUSPEND/RESUME was only ever implemented for SPARC workstations and certain high end servers. (On the workstations it was done for E*Star compliance. On the E10K class server -- and possibly others -- it was used to prevent changes to kernel memory while performing a DR operation on the memory board containing the kernel cage.) I don't believe any "modern" SPARC server still relies on it, although I suppose it might be used on the high end M class or E25Kish systems. > > The x86 support for ast won't use the SPARC kernel device driver, nor > an x86 kernel driver, so the quiesce question is not a factor for ast > on x86. At least, not as a part of this project. OK, that seems fair enough. If you're not using a kernel driver on x86, even the SUSPEND/RESUME support is probably deferrable. I'd be surprised if this driver were used on any SPARC system capable (at this time) of suspend/resume. -- Garrett > > -- Eric > > > Garrett D'Amore wrote: >> Eric Sultan wrote: >>> The project team agrees that quiesce and suspend/resume should be >>> supported. >>> >>> Solaris 10 deliveries will include support for DDI_SUSPEND and >>> DDI_RESUME. >>> >>> Post-Solaris 10 deliveries will also include support for >>> quiesce(9e). In the initial deliveries, the quiesce vector in the >>> dev_ops struct will be set to ddi_quiesce_not_supported if the >>> target OS doesn't yet have any quiesce users. When the Fast Reboot >>> team delivers code that uses quiesce, the ast driver will replace >>> that vector with one to a device-specific quiesce entry point. >> >> I'm happy with this response. Note that on x86, there are already >> quiesce() users. So on x86 at least, quiesce should be supported on >> Nevada from the initial point of integration. >> >> (As an aside, I'm not sure there is any point in doing >> DDI_SUSPEND/RESUME on Solaris 10. None of the SPARC platforms in >> question can SUSPEND/RESUME -- or at least I don't think they can -- >> and x86 SUSPEND/RESUME is only supported on Solaris >> Nevada/OpenSolaris. So you might have a difficult time verifying >> suspend/resume on S10.) >> >>-- Garrett >>> >>> -- Eric >>> >>> >>> >>> >>> Sherry Moore wrote: quiesce(9E) is a newly (since build 100) added dev_ops entry point http://docs.sun.com/app/docs/doc/819-2255/quiesce-9e?l=en&a=view The Fast Reboot team would like the SPARC AST project team to state in the final case material 1. that quiesce(9E) will not be implemented at initial integration and why. 2. their commitment to implement quiesce(9E) when SPARC Fast Reboot project is in progress. Thanks, Sherry On Wed, Dec 10, 2008 at 10:28:56AM -0800, Garrett D'Amore wrote: > At PSARC today, this was let run, because of the question of > quiesce(9e) support. PSARC would like to see either the project > team agree to implement quiesce(9e) or a written statement from > the Fast Reboot team clarifying that quiesce() is not needed for > this project. > > (Note that while I understand the project title indicates SPARC, > earlier discussion has revealed that this project also shares code > with x86. I personally believe the quiesce question is more > germane to x86 at the moment, but I'm not sure if that is > tantamount to granting a blanket waiver for SPARC drivers.) > > The same questions can also be made of DDI_SUSPEND and DDI_RESUME, > though I perceive that there is less urgency here (given that this > is intended for server products). > > As a final personal note, I expect that if the project team simply > agrees to implement both suspend/resume and quiesce, that this > case will be approved with no further objections. > >- -Garrett > >>> >> >
PSARC/2008/597 vdiskadm
Hi I created a vdisk as below: vdiskadm create -t vmdk:sparse -s 8g -c "My Disk" /export/home/vdisk/solaris1 I don't know how to use this virtual disk, is it for domU? I have created a guest os on my xvm server, can i add this virtaul disk to the guest os ? thanks -- This message posted from opensolaris.org
