[lkml]   [2006]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Generic battery interface
    Hi Pavel,

    > > > We also need to decide on clear convention about units. Are they in
    > > > the output and/or filename? Filename is best, I think, since it's
    > > > impossible to miss and works nicely for input attributes too.
    > >
    > > Actually, this whole thing could probably just go under the 'hwmon'
    > > interface, as it already handles other hardware monitoring events. I
    > > don't see how a battery would be any different, do you?
    > Heh... yes, hwmon already has voltage, current, and more importantly,
    > a maintainer.
    > I'd still prefer batteries to go into /sys/class/battery/... they are
    > really different from lm78-style voltage sensor and I'd not expect
    > battery applet to understand all the fields "normal" hwmon
    > exports.

    This probably doesn't matter much, every application can handle only
    the subset it is interested in. For example a dockapp displaying the
    system temperature only cares about the temp* files and ignores the
    in*, fan*, etc. files.

    However, it would be convenient if the battery monitoring application
    had an easy (and non heuristic-based) way to distinguish between a
    battery and a hardware monitoring chip. In that sense, having a
    separate class makes sense. This doesn't prevent the battery drivers to
    use the same conventions used by the hardware monitoring drivers.

    > But conventions developed by hwmon group look sane and usable.

    Nice to read this for a change, usually people have only complaints
    about it ;)

    > Actually I do not see "hwmon infrastructure" to exist. Every driver
    > just uses sysfs directly. I'm not sure that the best option --
    > "input-like" infrastructure can make drivers even shorter -- but
    > perhaps just directly using sysfs is best for simple task like a battery?
    > Jean, any ideas?

    I guess we never felt any need for an "infrastructure", else we would
    have created it. I have no idea what the "input infrastructure" looks
    like so I can't compare. If you have something to propose which would
    refactor some code amongst the hardware monitoring drivers or would
    otherwise makes thing better, speak up :)

    Note that the hwmon class is merely a way to find out which devices
    have hardware monitoring attributes. There are no class attributes in
    use. The reason is historical, and also due to the fact that no two
    hardware monitoring chips have the same set of features.

    Jean Delvare
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-07-30 14:33    [W:0.023 / U:1.836 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site