I'm sponsoring this self-review case for Raymond Chen.
-Artem
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2010 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
USB CDC ECM driver
1.2. Name of Document Author/Supplier:
> Currently, the "hal" daemon that is responsible for automatically mounting
> media is unable to mount read-only SDcard (write protect tab enabled) media,
> because it has no way to detect this media needs to be mounted read only.
> (hal is implemented with run-time checks for floppy media, and w
> Hence, we feel it is appropriate to remove the bpp driver from Nevada,
> as the driver will not be useful to users of OpenSolaris or Solaris Next.
I think this case would benefit from explicitly stating what will happen
to and the interfaces it defines. There are currently
consumers in the k
>> /dev/[r]sr%d/dev/[r]dsk/*sd/atapi cdrom drives
>
> This one I do see quite frequently used in shell scripts, in order to
> find which of the disk devices is the cdrom/DVD drive on the system.
>
> What's the replacement mechanism for doing this in shell scripts?
This
With the Uncommitted stability level, this proposal was approved at
yesterday's PSARC meeting.
-Artem
> If you'd be willing to change that portflag string from "Stable"
> (which isn't one of the current stability levels anyway) to
> "Uncommitted", then I'd give it a +1.
The project team informed me that they decided to change stability to
Uncommitted.
-Artem
Timeout is approaching: there's been a bit of discussion and so far
we've got one abstain (Garrett) and no other votes.
-Artem
On 04/28/09 15:07, Artem Kachitchkine wrote:
>
> I'm sponsoring this fasttrack for Guoqing Zhu. The timer is set for
> 05/06/2009.
>
>
> I'm *really* not a fan of inconsistent property handling -- magic
> encoded strings like what is proposed here for portflag seems,... ugly.
I've heard of magic numbers, but this is the first time I'm hearing of
magic strings. What's wrong with descriptive names? Would it help if
they were i
I'm sponsoring this fasttrack for Guoqing Zhu. The timer is set for
05/06/2009.
My understanding is that even though the initial delivery is for
usbser_edge driver, the proposed interface can be adopted by other USB
serial drivers and new modes added in the future.
-Artem
Template Version: @
>> For cases like CD ripping, we should be able to provide apps with a
>> functional API, hiding USCSI implementation in the privileged component,
>> preferably sd driver, extending cdio(7I) if necessary; failing that,
>> smserverd would probably be another choice. We now also have the
>> improved
On 04/01/09 01:51, Darren J Moffat wrote:
> Understood and that is great information, does smserverd allow for this
> kind of nasty to get through it ?
Yes, as does any solution that allows apps to use uscsi directly.
> If possible I'd like to see it used rather than handing out sys_devices
> Giving out sys_devices isn't IMO the correct answer either -
> particularly given that sys_devices is such a big powerful privilege.
>
> Instead I'd rather see a privilege specifically for these USCSI ioctls.
> However that still leaves the issue of why aren't the DAC permissions
> enough ?
Darren J Moffat wrote:
> Why can't this case and the braseo one use the services provided by
> svc:/network/rpc/smserver ? See rpc.smserverd(1M).
Please don't use smserver/libsmedia to gain USCSI privileges.
(Longer answer:
http://www.mail-archive.com/opensolaris-discuss at
opensolaris.org/ms
> We seem to be doing a good job coming up with names that we definitely
> shouldn't use :-) I still hope Rishi can put forth a new name for these
> handy objects. (Naming is hard -- but important.)
We just need to break out of the confines of the English language. Let
me throw in a few, just
Peter Memishian wrote:
> FWIW, I have to agree with Scott on this one (and I'd earlier made a
> similar comment). Everyone seems to agree this is project is a great
> idea, and I've little doubt it will be widely used -- so why saddle it
> with a name that is a homonym of one of the most basic Uni
> Simulated links (simlinks) are pseudo GLDv3 network devices that aid in
> the creation of point-to-point network links on a system. They are
> intended to be a testing resource for OpenSolaris developers. Simlinks
> should help in developing test suites that can run with minimal networ
On 03/02/09 03:29, Cecilia Hu wrote:
> I am sponsoring this case for Tim Chen. It is to provide a new
> wireless(IEEE802.11b) driver, atu(7D), for Atmel AT76C50x USB card.
I'd be the last to complain about naming, so let me start by saying: +1
on the case. But a note for the future: we've tried
Liu, Jiang wrote:
> Hi Randy, Garrent and Artem,
> I have made some changes/enhancements to CPU idle notification PSARC
> onepager according to kindly feedbacks from PSARC/Tesla review. Could you
> please
> help to review it again? The attachments is the latest PSARC onepager and a
> diff
> 4.2.5. Register CPU idle notification callback
> int cpu_idle_register_callback(uint_t priority,
> cpu_idle_callback_t *callbackp, void *arg, void **hdlpp);
> This interface registers a callback to be called when CPU idle state
> changes. All registered callbacks
This case is now approved.
The only change to the initial proposal is that the default value of the
"eject_button" SMF property for rmvolmgr will now be boolean true,
rather than false, as discussed earlier.
-Artem
On 02/02/09 05:56, Joerg Schilling wrote:
>> The latest version of HAL provides interface locking:
>>
>> http://people.freedesktop.org/~david/hal-spec/hal-spec.html#locking
>>
>> Applications like cdrecord can grab the lock for the duration of the
>> critical operation, which would prevent any DB
> This would change the behavior. Do you plan to alternatively allow to
> have the eject button blocked as before? Note that people may likke to have
> the
> button locked in order to prevent to eject the media by accident.
We provide an SMF property for rmvolmgr for this. There is no similar
On 01/29/09 10:14, Darren J Moffat wrote:
> I'm happy except for the overly conservative behaviour with rmvolmgr
> being different to when gnome is running. I think the default should
> be the same as when gnome is running but keep the very useful SMF
> property so that the ultra paranoid can
Garrett D'Amore wrote:
> Darren J Moffat wrote:
>> I'm happy except for the overly conservative behaviour with rmvolmgr
>> being different to when gnome is running. I think the default should
>> be the same as when gnome is running but keep the very useful SMF
>> property so that the ultra par
sical eject button
1.2. Name of Document Author/Supplier:
Author: Artem Kachitchkine
1.3 Date of This Document:
29 January, 2009
4. Technical Description
4.1. Summary
For years, operating systems have allowed users to unmount and
eject removable media by pressing the phy
> to be able to identify the Sun Ray session a process should be running
> under, which means some new API and probably a new field or two in the
> uarea.
And subsystems other than audio could benefit as well.
-Artem
I missed this during case preparation: what is the requested release
binding?
> - Provide a mechanism for drivers to get more interrupts.
>
> The feature is optional so drivers that don't use it still work even
> if the system has implemented support for the feature. And conversely,
> drivers
I'm sponsoring this fasttrack for Scott Carter. It is set to timeout on
10/15/2008. Given that this is a relatively minor amendment to a larger,
approved case PSARC/2004/253 "Advanced DDI Interrupt Functions", I think
it qualifies as a fasttrack. As the discussion progresses, extending
the t
This case is now approved.
-Artem
I believe all issues have been addressed, so I'm marking this case
closed approved.
-Artem
Reminder: case times out this Friday. Before it can be approved, we need
at least one email confirming that it was reviewed by a living person -
if you qualify, looked at this case and liked what you saw, please speak up.
thank you,
-Artem
Darren J Moffat wrote:
> I need time to review this case but I may not be able to do so by the
> timeout on Wednesday, so please consider this a request for more time.
Correction: the timeout is on Friday, 9/26. Given that, do you still
need more time?
-Artem
I'm sponsoring this fasttrack for Susan Kamm-Worrell. In addition to
this proposal, a draft vdiskadm(1m) man page is in the case directory.
The timer is set for 09/26/2008.
-Artem
Template Version: @(#)sac_nextcase %I% %G% SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
I'm sponsoring this fasttrack for Mark Johnson. The timer is set for 09/26/2008.
-Artem
Template Version: @(#)sac_nextcase %I% %G% SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Block Tap Support for Solaris
1.2. Nam
Would it also be appropriate to point to the Writing Device Drivers book
as required reading for any driver writer? Besides essential technical
info, it includes some best practices -ish advice, as in chapters:
Considerations in Device Driver Design
Choosing a Locking Scheme
Defensive Programmi
/usr/share/usb.idsProject Private A list of all known USB ID
This is inconsistent with PSARC/2005/399:
/usr/share/hwdata/usb.ids Volatile
-Artem
>Ubuntu has cdrdao in its repository,
>we need to add it also into our repository.
> and the existing cdrecord (PSARC/2005/520 & PSARC/2006/089) which even
> has a -dao option.
And to expand on that: what cdrao can that cdrecord cannot? Is cdrao
included in Debian-based distros for te
I have no further questions.
-Artem
> This case is due timeout on Tuesday, any further issues, please send an
> email before then.
>
> Thanks
>
> --Irene
> Halton Huo wrote:
>> On Wed, 2008-06-18 at 23:48 -0700, Artem Kachitchkine wrote:
>>
>>>
The "signal between X and Y" or "X sends signal to Y" language is
confusing. DBus signals in general are not peer to peer, they are
messages broadcast on a bus. Arbitrary number of applications can listen
on the bus. It is possible, however, to establish a peer to peer DBus
connection between
Case is approved.
-Artem
By request from a PSARC member, the timeout is extended until this
Friday, April 4th.
-Artem
> - what is the support model?
The Best Practice is to prop oneself with an outstretched limb against a
firm, vertical surface. Of course, frequent usage of beer(1) makes it
difficult to distinguish between vertical and horizontal characteristics
of a surface, which, in my opinion, is one of t
> I thought these interfaces would rise to Committed as part of making GLDv3
> public. Is that incorrect?
Are dlmgmt upcalls and DLDIOCSETPROP part of GLDv3? My understanding
that, of all interfaces presented in this case, only mac_prop_* are part
of GLDv3 - and none of those use either MAC na
> So then could someone clarify why we must complicate the interface with
> two different forms of access (macname and linkid)? Is it because a
> macname is not unique for VLANs, and a linkid for the mac may not yet
> exist? If so, I guess we can live with the complexity until Crossbow
> integra
> That was not the nature of my code-review comment. The initial Brussels
> code, before that code-review, used link names (not MAC names). It is
> not sensible to pass link names down to the kernel via an ioctl
> interface, as the kernel has to translate that to either a datalink_id_t
> or
> A nit: plumb/unplumb terminology has generally been restricted to IP
> interfaces rather than links (since IP interfaces actually have STREAMS
> modules associated with them). It'd be good if we could generally avoid
> using plumb/unplumb terminology with regard to links.
OK.
> > This flag i
>> ifconfig plumb
>> dladm init-linkprop
>>
>> We propose that this happens automatically each time a link is plumbed.
>
> How do I, as an admin, plumb an interface with no configuration for
> diagnostic purposes?
>
> It should also be noted that it is common practice in fora such as
1.2. Name of Document Author/Supplier:
Author: Artem Kachitchkine
1.3 Date of This Document:
26 March, 2008
4. Technical Description
4.1. Summary
PSARC/2007/429 introduced network driver properties that persist across
system reboot, but not across link plumb/unplumb. This
Case is now approved.
-Artem
2.22
1.2. Name of Document Author/Supplier:
Author: Artem Kachitchkine
1.3 Date of This Document:
17 March, 2008
4. Technical Description
4.1. Proposal
GNOME 2.22 is coming to Nevada. A new component, GVFS, relies on
some trivial libhal functions that debuted in HAL
Case is approved.
-Artem
> I was initially going to send a very similar comment then I remembered
> that "high-speed" is actually USB terminology in common use.
>
> IMO it wasn't forward thinking terminology for considering future faster
> (even-higher-speed then no-really-we-mean-it-this-time-high-speed) but
> looked
I am sponsoring this fast track for Strony Zhang.
Requested binding is minor, timeout 02/07/2008.
-Artem
Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Additional USB Devic
This case is now approved.
-Artem
I am sponsoring this fast track for Raymond Chen.
Requested binding is minor, timeout 1/18/2008.
-Artem
Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Integrate OpenUSB int
> Hummm, I understand that hald is the mechanism for enforcing the
> authorization, however I wouldn't expect it to be part of the
> authorization name. I'd more expect the authorization name to
> represent the functionality being authorized within the powermanagement
>
> Heh. That's a nice theory. Except for one "itsy bitsy little issue".
> Except for drivers for a few well known classes, you *cannot* adhere to
> the DDI simply because there is no DDI compliant way to populate /dev!
> The devfsadm plugin framework is clearly not public (and its entirely
Maintaining good programming practices is largely orthogonal to the
bundled/unbundled discussion. If it's easier for someone to think in
terms of consolidations, recall that the driver consolidation has been
on the table and imagine that it happened. If I can uninstall a driver
package (and th
> My point is that the project needs only a private interface between its
> user and kernel bits. It need not be visible to anything else.
The project's kernel and user bits utilize devfs as an interface
intermediary. It is not a direct interaction.
> Yes,
> relying on it for unbundled softwa
Garrett D'Amore wrote:
> FWIW, I'd recommend *against* stashing a node in /dev. Better to just
> access the /devices node directly IMO. The /dev links are a convenience
> that is appropriate for "quasi-public" interfaces... you're not going to
> need the /dev link (won't this just live in some
>> It seems to me that multi-socket machines need to support
>> different speeds on different sockets.
>
> If I remember correctly, GPM doesn't allow you to configure speeds an
> individual processors or sockets.
Yes, it appears how this particular API is designed. More sophisticated
functiona
>> What happens when CPUs are DR removed/added ?
> The associated device objects should get removed.
Will that be achieved via DR sysevents or some other mechanism?
> The CPUFreq interface is associated with the "computer" device object,
> similar to system power management interface. Since it
> Each processor will have a cpu device object,
What happens when CPUs are DR removed/added ?
> Set* methods will not be called on each processor. It applies for all
> the processors.
Interfaces and methods are associated with objects. So what you're
saying is, even though a method is called
Garrett D'Amore wrote:
> Just a quick question on blk2scsa at the last meeting the members
> asked for more time (don't know which members they were, as I arrived a
> couple of minutes late). What I don't know is whether enough time has
> passed yet or not. Do any of the members still wan
You described properties and interfaces, but those do not exist in
vacuum, they must be associated with device objects that HAL maintains.
Could you expand on that. E.g. it appears that processor.* properties
belong to device objects with "processor" capability: will HAL create
one object per
Any update on that pesky ZFS?
-Artem
The case is now approved.
-Artem
> Yes, I intend to try it out.
Great.
> I'm not specifically targetting ZFS, but I
> can't see why it wouldn't work, other than the device id concern raised
> below.
Another vector to keep an eye on, wrt ZFS, is write cache (6424510 usb
ignores DKIOCFLUSHWRITECACHE).
-Artem
> I'm not sure about ZFS, but it is good enough for sd(7D) with PCFS.
IMO the proposal is incomplete without a clear statement about ZFS, even
it it's "unsupported", though I really hope for the opposite: USB
storage is the dumbest storage I've ever encountered (so far), yet you
can put ZFS on
> Commands
>
Does this command set translate into sufficient sd(7D) functionality to
be used with ZFS?
-Artem
I am sponsoring this fast track for Raymond Chen.
Requested binding is patch/micro, timeout 11/21/2007.
-Artem
Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
This information is Copyright 2007 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Support for is
> Certainly the transition in going from DDI compliant to
> non-DDI-compliant is not one that I would want to just sweep under the
> rug. Better to announce that transition up front, IMO. (And if going
> non-DDI compliant is required to fix a bug, my first question would be
> "why?")
I'm no
> What I'm talking about is an ARC requirement to *disclose* non-DDI
> interface consumption by drivers, and to strongly discourage the
> practice of going outside of the DDI for device drivers. I think that
> *is* an issue for PSARC at least.
How do you envision to enforce this in practice?
Why is this an ARC issue? Drivers don't usually go through ARC. it
should probably be on the ON C-Team Driver Checklist. Add DDICT to the
ON tool set and integrate it with wx.
-Artem
Case is now approved.
-Artem
Nicolas Williams wrote:
> On Tue, Sep 04, 2007 at 12:50:43PM -0700, Danek Duvall wrote:
>> On Tue, Sep 04, 2007 at 02:12:18PM -0500, Norm Jacobs wrote:
>>> I can envision a time when we might want to update it to recognize more
>>> device types. If we were to break this down to device-type and met
More time was requested at yesterday's meeting, so I'm extending the
timer until 9/12.
-Artem
>>> The HAL addon, hald-addon-network-discovery, doesn't currently
>>> discovery anything other than printers and we don't have plans to
>>> extend it to look for anything else.
>>
>> Is that "we" the printing folks or the more general set of people working
>> on HAL? I don't think I'd expect t
I am sponsoring this case for Norm Jacobs.
Requested binding is minor, timeout 09/06/2007.
-Artem
Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
This information is Copyright 2007 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Automatic discovery of netw
Timeout was reached without open issues and the case is now approved.
-Artem
I am sponsoring this case for Edward Gillett.
Requested binding is patch/micro, timeout 08/15/2007.
-Artem
Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
This information is Copyright 2007 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
MSI-X interrupt li
FWIW (likely not much), this reminds of the 'games' class of
applications, hinted at in the Filesystem Hierarchy Standard, which was
adopted in LSB.
/usr/games/ binaries
/usr/share/games/ static data
/usr/lib/games/ shared libs
/var/games/ high scores
The 'benchmarks' cla
The case was approved today.
-Artem.
I am sponsoring this case for Gaopeng Chen.
Requested binding is patch/micro, timeout 06/13/2007.
-Artem.
Template Version: @(#)sac_nextcase 1.61 05/24/07 SMI
This information is Copyright 2007 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
logindevperm device
84 matches
Mail list logo
