Guo-Fu Tseng wrote:
quoted text
> Jeff Garzik wrote:
[...]
quoted text
> >* we prefer not to add custom ioctls, but rather add functionality to 
> >ethtool.  in particular, JMESPIIOCTL does not appear to have any 
> >security checks, and is a potential security hole that permits an 
> >unpriveleged user direct access to hardware
> >
> 
> Should I add privilege check, or should(could?) I send a patch that add 
> ethtool interface for flash(For storing PXE code) read/write?

Flash devices are normally handled by MTD drivers.  However an MTD
driver that works through a network controller will normally need to
coordinate with the network driver.  We have an MTD driver for exactly
the purpose of updating boot code, but the coordinating mechanism
("driverlink") has not been accepted in-tree.

I think we would be happy to implement an ethtool API for flash
memory if this was agreed to be the right interface.  It just seems
like it would be duplicating the MTD API.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html