Stephen Hahn wrote:
* 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.
That will be impossible until you allow non-Sun folks and
non-Sun-business needs to determine ON. I don't see that as realistic
at this point.
The idea here is not to compete with ON, but to provide an *alternative*
when getting into ON is unrealistic.
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...
Okay, I'll have to research this. The problem isn't *installing* such
an IPS package, its figuring out how to *construct* one. (At least for me.)
$ 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.
Yes, basically a proto area -- although it has to include at least meta
data required to install the bits. I'd envisioned providing SVR4
packages as well, but if no distribution needs them and IPS works for
everyone, then we could just do that. I don't have a strong feeling one
way or the other -- I lean towards SVR4 just because that's what I know.
- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
