#ident "@(#)issues	1.9 07/10/17 SAC"

PSARC 2007/429:	Brussels - enhanced network driver configuration via dladm
Submitter:	Sowmini Varadhan
Owner:		James Carlson				
Intern:		Garrett D'Amore

Issues for inception (09/12/2007):

kb-01	'props' vs 'capabs'. Are both needed? what's the difference? what are
	the criteria for a device driver developer to express a certain
	feature as a property or as a capab (via the mac_capab_*() interface)?

kb-02	3.2.4, use of ddi_strtoul(). Why not offer the type as an attribute of
	a property that the framework queries (at the same time it asks about
	whether the prop is supported or not), then read/parse/convert the
	userland input as needed, and pass a properly typed prop value through
	the (*mc_setprop)()

kb-03	5.0.1
	driver.conf can carry per driver and per instance properties.
	What's the equivalent of per-driver in this proposal?

kb-99	(implementation nit) an enum type seems more suitable for pr_num (the
	scalar encoding of a prop type).

kb-98	Attempt to set a property on a device that cannot support it should
	fail with EINVAL or ENOTSUP, not ENXIO (No such Device or Address).

seb-01	brussels-umbrella.txt 3.5
	This is a subset of the ON GLDv3 drivers (and one that is under
	development and not yet in ON.)  Is the idea to convert all ON
	drivers?  If so, I'd state that instead of listing them here, as
	the list seems to be growing weekly.

seb-02	brussels-umbrella.txt 4.1.3
	I'm not sure I understand the semantics of this function.
	mac_register_t contains fields that are clearly immutable and
	only meant to be initial settings, and the structure does not
	contain the values of the properties that may be supported by
	the driver.  It would be cleaner (IMO) to add specific
	mac_update_*() functions for specific properties well-known to
	the framework (such as mac_update_sdu() for example).

ged-01	brussels-umbrella.txt 3.4
	I don't think drivers should use NDD *at all*.  If Brussels is going
	to achieve simplification for drivers, it should really provide a
	common way for drivers to support "private" properties, without asking
	them to resort to the very clunky NDD ioctls.  My hope is one day to
	eradicate all the different NDD implementations in drivers out there.

	But then I see in brussels pdf 5.0.2 you plan to use nd_param_t?
	This still seems a bit clumsy and insufficiently specified.  I'd
	like a lot more detail here before final commitment.

ged-02	general
	A lot of drivers have tweaking for loopback via IOCTLs.  I'd still
	like this to be "on the plan".  Loopback ioctls are important for
	SunVTS, but very clumsy to implement directly.  I think they might
	fit well to Brussels properties.

ged-03	For the record, I'm willing to update eri, dmfe, hme, afe, mxfe
	rtls, and iprb which are the drivers I've touched. 

ged-04	Why no WLAN drivers?  I'd really like to see some of the WIFI tunables
	handled here.

PSARC 2007/429:	Brussels - enhanced network driver configuration via dladm
Submitter:	Sowmini Varadhan
Owner:		James Carlson				
Intern:		Garrett D'Amore

Issues for commitment (10/17/2007):

jdc-1	Why does the release note say: "to be marked Obsolete in an
	[sic] future release"?  Shouldn't users start using dladm as
	soon as it integrates?  If so, then ndd is obsolete _now_.

	Same issue for ndd(1m) man page update: if users are supposed
	to switch now, then ndd for L2 admin is obsolete now, not
	later, and should be called out as obsolete.

	"Obsolete" means "still present in the system, but discouraged
	for use."

ged-05	What about power management of link interfaces? (e.g. switching 
	down to 100Mbps when traffic conditions permit it.) This will
	require some new properties, and maybe changes to the proposed
	adv_xxx properties.

djr-0	We need a way to selectively turn hardware checksum on/off,
	on a per-interface basis, so we can use it on NICs that have
	bug-free hardware checksum and disable it on those where it
	does not work.  This may be out of scope for brussels?

kb-04	Crossbow will define all properties that have to do with vnics,
	possibly using this framework, possibly different.
	The introduction of link_vnic_* does not belong here. It is not
	useful to commit to any property pertaining to vnics now.
	It's OK to issue an advice for the crossbow project to follow the
	framework defined here.