[PATCH 0/3] WOL: Add Wake On LAN support

[Holger Macht]

On Tue 14. Aug - 14:57:49, Bastien Nocera wrote:
> On Tue, 2007-08-14 at 15:44 +0200, Holger Macht wrote:
> > On Tue 14. Aug - 14:34:11, Bastien Nocera wrote:
> > > On Tue, 2007-08-14 at 15:21 +0200, Holger Macht wrote:
> > > > The following patch series adds support for Wake On LAN (WOL) to HAL. In
> > > > this context, adding Wake On LAN support means adding support for ethtool,
> > > > which is supported by various drivers.
> > > > 
> > > > I was surprised to see for how many systems this actually works. The
> > > > common problem is just that it's not configured correctly on most distros,
> > > > and that there is no easy way to enable/disable it from the desktop if
> > > > supported.
> > > > 
> > > > The patches add the following new interface to any network device with the
> > > > capability 'net.80203':
> > > > 
> > > >  org.freedesktop.Hal.Device.WakeOnLan
> > > > 
> > > > The interface provides the following methods:
> > > > 
> > > >  GetSupported(void)
> > > 
> > > As whether the device supports it is unlikely to change, why not make
> > > this a property?
> > > 
> > > You'd probably need to add the detection in the coldplug routine of HAL.
> > 
> > But it might change underneath us...
> 
> What would change? The device name? Or whether the device supports it?

The status, whether enabled or disabled.

I used to argue that this is completely fine, you just have to make sure
that HAL is the only one allowed to enable/disable Wake On Lan. However,
this can still change in this specific case. IIRC, for instance, some
drivers take the device down/up or reset the device on suspend, which
would completely slip through our attention without kernel
notification. We would also need a method to rescan the Wake On LAN
capabilities IMHO.

Adding the GetSupported(void) method to the coldplug detection of HAL
might make sense, though. I already have code, partly copied from ethtool,
to detect this from inside C code. It just makes it more complicated IMO
even though I'm an advocator of binary versus script code. However, I'll
check this again.

Regards,
	Holger