George Vasick wrote:
Attached, please find the revision 3 of the GCC proposal addressing the
following feedback:
1) GCC should install in /usr/bin/gcc/major.minor.
I haven't been following this case that closely but that concerns me
deeply. /usr/gcc/bin/major.minor/ I understand but
Dan Mick wrote:
putting offset on a new line by its own would
be my preference.
i realize that psarc isn't a democratic form, but regardless i'll put in
a vote for not having offset: on the same line as the filename.
I don't care all that much. For the majority of outputs, next to
George Vasick George.Vasick at Sun.COM writes:
Attached, please find the revision 3 of the GCC proposal addressing the
following feedback:
Thanks, looks much better overall.
1) GCC should install in /usr/bin/gcc/major.minor.
Darren already commented on this: I think this is meant to be
Darren J Moffat wrote:
George Vasick wrote:
Attached, please find the revision 3 of the GCC proposal addressing
the following feedback:
1) GCC should install in /usr/bin/gcc/major.minor.
That is a typo in the summary. The attachment shows the correct location:
/usr/gcc/4.3
Sorry about
The following case documents an intent to make a couple of minor bug-fix
related changes to the Boomer audio driver DDI. As the changes affect only
a consolidation private API which has not been released in any official
product yet, both the consumers and producers of the interfaces are owned
by
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
/etc/audio_numbers
1.2. Name of Document Author/Supplier:
Author: Garrett D'Amore
1.3 Date of This
Rainer Orth wrote:
George Vasick George.Vasick at Sun.COM writes:
Attached, please find the revision 3 of the GCC proposal addressing the
following feedback:
Thanks, looks much better overall.
1) GCC should install in /usr/bin/gcc/major.minor.
Darren already commented on this: I
On 11/23/09 12:51 PM, Garrett D'Amore - sun microsystems wrote:
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
/etc/audio_numbers
1.2. Name of Document
so if you've already talked to someone about devinfo snapshots then i
appoligize for the noise, but it really seems like you should be using
them in this case.
it seems like all the information your caching in this file is already
cached elsewhere. hence, this file seems like a bad idea because
Neal Pollack wrote:
On 11/23/09 12:51 PM, Garrett D'Amore - sun microsystems wrote:
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
/etc/audio_numbers
1.2. Name of
Its actually a bit more complex.
I need the *link number*, which is normally generated by devfsadm as
part of configuring a new device. And I need this in the kernel, so a
devinfo snapshot in user space is not (by itself) sufficient. See the
problem isn't that I just want to know what
On Mon, Nov 23, 2009 at 02:00:26PM -0800, Garrett D'Amore wrote:
Its actually a bit more complex.
I need the *link number*, which is normally generated by devfsadm as
part of configuring a new device. And I need this in the kernel,
so a devinfo snapshot in user space is not (by itself)
Edward Pilatowicz wrote:
On Mon, Nov 23, 2009 at 02:00:26PM -0800, Garrett D'Amore wrote:
Its actually a bit more complex.
I need the *link number*, which is normally generated by devfsadm as
part of configuring a new device. And I need this in the kernel,
so a devinfo snapshot in user
On 23/11/09 20:51, Garrett D'Amore - sun microsystems wrote:
This project will need to import the kobj interfaces for reading a file from
kernel space. While there is no case work behind these interfaces, we believe
they are Consolidation Private based on existing contracts for their use
from
On Mon, Nov 23, 2009 at 02:42:55PM -0800, Garrett D'Amore wrote:
Edward Pilatowicz wrote:
On Mon, Nov 23, 2009 at 02:00:26PM -0800, Garrett D'Amore wrote:
Its actually a bit more complex.
I need the *link number*, which is normally generated by devfsadm as
part of configuring a new device.
Edward Pilatowicz wrote:
On Mon, Nov 23, 2009 at 02:42:55PM -0800, Garrett D'Amore wrote:
Edward Pilatowicz wrote:
Yes, I think this is a relatively recent addition, but the /dev
content is in libdevinfo, as I've since discovered.
well, if s10 fcs qualifies as recent, then
Revised proposal. I presume this restarts the timer?...
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
pfiles offset
1.2. Name of Document Author/Supplier:
On Nov 20, 2009, at 11:25 AM, Nicolas Droux wrote:
Seb,
My intent is to include this entry point as part of the GLDv3 APIs being
committed. It is documented it in the mac(9F) man page draft [1],
but I did not list it in the overview. I will update the spec to list it
there as well.
The
Amit Gupta wrote:
Updated the attached ARC case with the new file layout as suggested.
The latest updated version of the doc is in the case directory
(materials/collectd.txt)
The case timed out on 11/13 and all the discussion in this case has
converged, marking it closed.
--
Jyri J. Virkki
19 matches
Mail list logo
