[patch] remove wireless support

[Kay Sievers]

On Thu, Jun 03, 2004 at 11:07:57AM +0200, Owen Fraser-Green wrote:
> Hi,
> 
> On Wed, 2004-06-02 at 17:25, Robert Love wrote:
> > Yup, and this will undoubtedly lead to the need to have other libraries
> > built on top of HAL (and, really, it makes sense to have a class-
> > specific library on top of HAL).  And once there is a lib on top of HAL,
> > the abstraction might as well be there.
> 
> Let's say there are four levels of abstraction:
> 
> 1) The inherent properties of the physical device
> 2) The properties that the operating systems uses to address the device
> 3) Device settings
> 4) Actually using the device for its intended purpose
> 
> Now, HAL clearly already tries to do 1) and 2) and everyone's happy
> about. I think we're also in agreement that abstracting 4) is pretty
> silly and I'm definitely not advocating that. 3), though, is the grey
> area and, really, this wireless properties thing isn't the only time
> it's been stepped into. Hard drive volumes, I believe fall into this
> category, for example (it's a UNIXism to view them as devices). So does
> ethernet MAC address and rate. By applying the setting vs. inherent
> property yardstick then why not get rid of these too?

I don't think, the border should not be the physical hardware. Volumes
are independend devices, regardless of their place on the system.
I think HAL should do device discovery only to the point the device is
classifiable and it can create a unique identifier(udi) to store
system(fdi), user(capability attributes) and config values for this
device.
HAL should also be able to merge the system/user device data if the same
device is discovered in a different location or if more than one
identical device is discovered. MAC adresses, serial numbers or volume
labels are great for this job.
HALs polling for media changes falls into device discovery, only the
polling for the network link state is now a grey area.

If we want a OS independend interface for wireless networks, someone may
define a api for it and make a new abstraction library, that uses hal to
discover the devices and possibly reads HAL config values, and provide the
glue between the systems lib and the new abstraction library.
This way applications can use this new library to be OS independent and
HAL doesn't bloat with APIs for all possible classes of devices.

Maybe the the _name_ HAL is the really misleading thing here?
Hey, we can call it "City of Devices" :)

Kay

_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal