Patches

[David Zeuthen]

Hi,

Sorry for the delay,

On Fri, 2005-06-24 at 18:01 +0200, Kay Sievers wrote:
> > > >   From my point of view, it is not a problem of compiling HAL on
> > > > Solaris but a mistake with the types.  I mean, the private kernel types
> > > > shouldn't be used in user space programs.
> > > 
> > > Seconded, /usr/include/stdint.h exists for this purpose and should be
> > > used for portability.
> > 
> > Sounds good and reasonable to me and if klibc doesn't have this
> > volume_id should probably just work around that. Kay, is this OK with
> > you?
> 
> I hate C99 types! I don't buy words like "wrong types" and "mistake" in
> this context. I like it to have the same structs as the kernel, where I
> copied it from. I don't see a problem adding the few typedef's to make
> it compile on a different platform cause these types are private to
> volume_id itself and not in the public header (volume_id.h).
> 
> But sure, I don't really care and if it makes you guys more happy then
> just go ahead and switch it. :)

So, it sounds to me that the best solution is to put typedef's in some
(private) volume_id header so the code can stay close to the source it
comes from (the Linux kernel). This should be easy and I'd do this
myself but I don't currently have access a non-Linux system; Alvaro, any
chance you might cook up a patch to do this?

> Btw:
> We are planning to move all the id stuff into udev and provide this
> information from there to HAL.
> udev will need this information for modern persistent device-names we want
> to introduce (there will be a talk at OLS this year about it). udev and
> its probing helpers also have the knowledge about the low-level to know what
> can safely be asked from a device (remember the scsi INQUIRY that stops
> storage devices from working). So volume_id and drive_id can be removed from
> the HAL tree soon and maintained at a lower level.

This will be quite sweet of course.

However, remember that we want to support things like SetVolumeLabel()
from HAL (the thinking is that this method is triggered when you do a
rename in e.g. Nautilus or Konqueror or whatever) and also Rescan(). 

So, I'm not sure you want stuff like this in udev but I could be wrong -
do remember, we can't force a partition-table reload just because we
change a label on a filesystem on one of possibly many partitions so,
really, there is no or little way that udev will ever learn about such
changes (and it shouldn't need to)

Another thing is that, theoretically, not all kernels (dunno if Solaris
supports it for instance) may support such a feature. Also, I don't see
a problem with us having a separate copy in the HAL trees though it's of
course always good to keep the amount of code down.

    David


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