[patch] wireless patch, take 2
rml at ximian.com
Thu May 27 14:06:17 PDT 2004
On Thu, 2004-05-27 at 22:40 +0200, David Zeuthen wrote:
> Nice catch, you're right, I didn't think of that, sorry.
Only because I am one of those people who hard code my ESSID, I
But the thinking comes from the way we do stuff in the kernel, too: if
HAL is the be-all end-all for device access, it must enforce *zero*
policy because we never know (and we don't want to influence/dictate)
what sort of code is built on top.
> The thing is that I do think the HAL should offer some kind of
> manipulation of the hardware, hence the API suggestion. It seems like a
> nice way to offer this through setting properties but I'm not completely
> sure how it would work. Hence, why I'd like to see some discussion of
> the wireless network usecase which may be one of the more complicated
Yah. One thing about providing richer API's: they could always be
provided by HAL-based libraries that sit on top of HAL and wrap and
extend its functionalities. See the libinput library I posted earlier
So HAL could stay minimal around the basic key/value set/get idea.
> Remember, for reading information we also have what I've called
> conditions that complement properties, e.g. a HalDevice can emit a
> DeviceCondition. This is used for things that not easily expressible in
> properties such as "this volume was unmounted" (implemented) or
> "processor is overheating" (not yet implemented).
Or overeating :)
> It seems whether we use properties or an org.freedesktop.Hal.Device like
> API to manipulate a device is largely implementation detail to me, but
> the latter approach does offer a lot more flexibility.
I do agree that using a richer API gives us more flexibility, especially
to do access controls, which may well be very important.
hal mailing list
hal at freedesktop.org
More information about the Hal