* Garrett D'Amore <gdam...@sun.com> [2009-10-28 17:46]:
> Stephen Hahn wrote:
>> * Garrett D'Amore <gdam...@sun.com> [2009-10-28 16:12]:
>>
>>> * containing platform support and drivers not in ON
>>> * drivers might also include userland components (X11 modules?)
>>
>> Are these only drivers that have been de-supported, or are you
>> encouraging new driver development as well?
>
> I don't see why new drivers couldn't be done here... eventually such
> drivers might transition to ON, but this would be a low barrier way to
> get stuff "out there".
I would rather see an effort to continue to work on easing the ON path
for new driver support than introduce a competitor.
>>> 3) Sun would have no official support for this new consolidation.
>>>
>>> * no support in bugster for this stuff
>>> * not part of any official Sun distro
>>> * caveat emptor
>>>
>>
>> If there's no SCAs required, then source in this consolidation will
>> have an extra hurdle (potentially insurmountable) if, after a period
>> of time, its maintainers want to port it to an SCA-requiring
>> consolidation. (My suspicion is that a revision sequence without SCAs
>> covering each step will result in a longer diligence check. Also, you
>> haven't stipulated the set of software licenses allowed.)
>>
>
> We import stuff from other FOSS sources into ON all the time. It might
> be that the combination of CDDL and no SCA is toxic, but other licenses
> (e.g. BSD licenses) don't have this problem.
Without the SCA, it means that every import will go through the OSR
process, which is the diligence I mentioned above. Keep good notes,
or require an SCA. (The BSD license isn't a panacea, as it lacks any
coverage of applicable patents.)
>> It might be interesting to have the output of this effort distributed
>> via the contrib/ repository--that work has a similar "at own risk"
>> aspect, and has a submission and acceptance policy already in place.
>> (So the Maintained Open Legacy Drivers (?) consolidation could focus
>> on code, building, and testing.)
>
> That's a good idea. Although at present I have been unable to get any
> information from the IPS folks about what is required to deliver a
> *driver* via IPS. (Specifically there is the question of handling the
> postinstall requirements for drivers -- you have to run add_drv.)
Image packaging appears to successfully install drivers with some
regularity. Let's see...
$ man pkg.5
/Driver
...
Driver actions
The 'driver' action represents a device driver. It does not reference
a payload: the driver files themselves must be installed as file
actions. The following attributes are recognized (see add_drv(1m) for
more information):
name The name of the driver. This is usually, but not always,
the filename of the driver binary. This is the driver
action's key attribute.
alias This represents an alias for the driver. There may be
more than one alias attribute for any given driver.
There are no special quoting rules necessary.
class This represents a driver class. There may be more than
one class attribute for any given driver.
perms This represents the filesystem permissions for the
driver's device nodes.
clone_perms This represents the filesystem permissions for the
"clone" driver's minor nodes for this driver.
policy This specifies additional security policy for the device.
There may be more than one policy attribute for any given
driver, but no minor device specification may be present in
more than one attribute.
privs This specifies privileges used by the driver. There may
be more than one privs attribute for any given driver.
devlink This specifies an entry in /etc/devlink.tab. The value
is the exact line to go into the file, with tabs denoted
by "\t". See devlinks(1M) for more information. There
may be more than one devlink attribute for any given
driver.
For a long example driver action:
$ pkg contents -m SUNWintgige | egrep ^driver
You can also grep for driver in /var/pkg/pkg on a typical OpenSolaris
system for other examples.
> We also need to make a consolidation available in tradition form so
> other folks can build LiveCDs of their own, or other distros can import
> it. (Imagine a legacy version of milax, for example.)
If you mean a proto area, then, yes, that's polite.
- Stephen
--
s...@sun.com http://blogs.sun.com/sch/
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
