All of lore.kernel.org
 help / color / mirror / Atom feed
From: Havoc Pennington <hp@redhat.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: Hardware Abstraction Layer
Date: Wed, 01 Oct 2003 01:30:08 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-106497200208294@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-106345989228476@msgid-missing>

Hi,

I just learned from a comment on gnomedesktop.org that I missed most of
this thread, it landed in the wrong mail folder or something. ;-)

On Fri, 2003-09-19 at 20:12, Greg KH wrote:
> > Things aren't handled properly today in the sense that there's no UI on
> > it, there's no integration with applications. To add that on the
> > desktop/app level, we first have to have a single API that will work
> > with different kinds of device and on different operating systems.
> 
> Hm, for a lot of this a UI isn't needed, right?  The user doesn't need
> to know that a driver was just automatically loaded for their device,
> correct?

That's right. The bulk of the UI should be about using devices rather
than getting them connected and working.

> Again, there are very notable exceptions, the digital cameras supported
> by gphoto2 and the USB scanners supported by xsane, both using userspace
> only code.  I'm just pretty skeptical that something can be created that
> would allow OEMs to plop into a userspace location that would enable
> device support across multiple operating systems.  But please, prove me
> wrong, I will be very happy.

Ah, I don't really mean that the OEM interface would be OS-independent;
either the file plopped would have to contain OS-specific portions, or
there would be a per-OS file. That's OK since we can expect an OEM to
deal with each OS independently, as they only have 1 device * N OSes.
It's the app developers that have to be insulated from M devices * N
OSes.

The OS independent portion is the part the app sees. Some properties
exported by the HAL are probably even OS-specific, but the point is
there's an OS-independent core/subset. (i.e. the idea is to let you
write portable code, not to keep you from punching down to OS details if
you want)

> I understand this.  The kernel doesn't contain #ifdef hell for that very
> reason.  But this is my main point as to how this might get very tough
> for having cross platform support.  The BSDs support lots of USB devices
> today in a very different manner than Linux does.

I think of it as "portability by subdirectory" ;-)

You have an API that apps talk to, and then some generic code, and then
a per-OS backend with a subdirectory for each backend:

 hal/
   include/
     hal/hal.h
   generic/
     hal.c
   linux/
     usb.c
   freebsd/
     usb.c

It isn't so much that the freebsd/ subdir is populated immediately, but
rather that when someone appears with the skills and motivation they can
add that subdir without having to rearchitect everything.

The desktop userspace doesn't have a list of required platforms so much
as the requirement that "if someone is actively maintaining a platform
they can keep that platform working"

> I'm happy to see this work happening, and if there's anything that you
> need from the kernel, hotplug scripts, or udev that I can help out with,
> please let me know.

I really appreciate your interest/help, btw.

I'm curious how many iterations of all this we'll go through before
we're happy with it. Wait, I've worked on software long enough to know
the answer is "infinite"... ;-)

Havoc




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

      parent reply	other threads:[~2003-10-01  1:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-13 13:30 Hardware Abstraction Layer David Zeuthen
2003-09-14 22:34 ` Joerg Sommer
2003-09-16 16:39 ` Greg KH
2003-09-17  0:40 ` David Zeuthen
2003-09-18  0:29 ` Greg KH
2003-09-18 11:24 ` David Zeuthen
2003-09-18 17:36 ` Greg KH
2003-09-18 18:30 ` Havoc Pennington
2003-09-18 20:35 ` David Zeuthen
2003-09-19 20:11 ` Joerg Sommer
2003-09-19 23:12 ` Greg KH
2003-09-20  0:12 ` Greg KH
2003-09-20  0:17 ` Greg KH
2003-09-20 19:31 ` Joerg Sommer
2003-09-21  6:42 ` Greg KH
2003-09-21 20:56 ` David Zeuthen
2003-09-24 21:08 ` Greg KH
2003-09-29 20:50 ` David Zeuthen
2003-10-01  1:30 ` Havoc Pennington [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-hotplug-106497200208294@msgid-missing \
    --to=hp@redhat.com \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.