[lm-sensors] alarm files one file per sensor vs file with bitmask?

[lm-sensors] alarm files one file per sensor vs file with bitmask?

[Hans de Goede]

Hi all, Jean,

Jean I would like to submit a version of the abituguru for merging, but 
I would like to modify it (if needed) to match your decision on this 
first. Can you take a decisision on this please?

Or shall I just submit the abituguru driver as is and submot an update 
if needed later?

Regards,

Hans

[lm-sensors] alarm files one file per sensor vs file with

[Jean Delvare]

Hi Hans,

On 2006-03-16, Hans de Goede wrote:
> Jean I would like to submit a version of the abituguru for merging, but
> I would like to modify it (if needed) to match your decision on this
> first. Can you take a decisision on this please?
>
> Or shall I just submit the abituguru driver as is and submit an update
> if needed later?

No, let's decide now and have your driver follow that decision right
away, that's less work for everyone, and will let you do the user-space
part faster too.

We will go with individual alarm files, as I had been proposing. I will
not have the time to submit a new documentation patch before next week,
but basically it's just what my previous patch was saying. Follow the
same naming scheme for beep, alarm_mask and shutdown (the later two
being only used by your driver AFAIK.)

Hans, I'd like to thank you for your constructive criticism with regards
to this technical choice we had to make. Some of your objections had
great merit and without Greg (and others) clearly speaking in favor of
individidual files, I would have had a hard time taking a decision. I
really hope that the sysfs polling capabilities Greg has been mentioning
will let us speed up user-space when writing this new library I have in
mind. I have to admit I don't quite see how at the moment, though.

Now I understand that its not the best thing that could happen for your
abituguru driver, but this is really only one driver amongst four
dozens, and almost all other drivers will be better with this approach.

Thanks (and sorry for being slow),
--
Jean Delvare

[lm-sensors] alarm files one file per sensor vs file with

[Jean Delvare]

On 2006-03-16, Hans de Goede wrote:
> > We will go with individual alarm files, as I had been proposing. I will
> > not have the time to submit a new documentation patch before next week,
> > but basically it's just what my previous patch was saying. Follow the
> > same naming scheme for beep, alarm_mask and shutdown (the later two
> > being only used by your driver AFAIK.)
>
> Ok,  got a link handy to the patch you're talking about? Otherwise I'll
> scim the archives.

This post:
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-March/015502.html

Or you can get the patch file directly from here:
http://khali.linux-fr.org/devel/i2c/linux-2.6/hwmon-sysfs-interface-individual-alarm-files.patch

--
Jean Delvare

[lm-sensors] alarm files one file per sensor vs file with

[Hans de Goede]

Jean Delvare wrote:
> Hi Hans,
> 
> On 2006-03-16, Hans de Goede wrote:
>> Jean I would like to submit a version of the abituguru for merging, but
>> I would like to modify it (if needed) to match your decision on this
>> first. Can you take a decisision on this please?
>>
>> Or shall I just submit the abituguru driver as is and submit an update
>> if needed later?
> 
> No, let's decide now and have your driver follow that decision right
> away, that's less work for everyone, and will let you do the user-space
> part faster too.
> 

I agree, but I didn't know if you were ready to take a decission.

> We will go with individual alarm files, as I had been proposing. I will
> not have the time to submit a new documentation patch before next week,
> but basically it's just what my previous patch was saying. Follow the
> same naming scheme for beep, alarm_mask and shutdown (the later two
> being only used by your driver AFAIK.)
> 

Ok,  got a link handy to the patch you're talking about? Otherwise I'll 
scim the archives.

> Hans, I'd like to thank you for your constructive criticism with regards
> to this technical choice we had to make. 

You're welcome.

> Now I understand that its not the best thing that could happen for your
> abituguru driver, but this is really only one driver amongst four
> dozens, and almost all other drivers will be better with this approach.
> 

I understand, no problem, this will delay the uguru patch a bit though, 
I have to find some time todo this, probably not before next week.

> sorry for being slow

No problem, processes like these take time


Thanks & Regards,

Hans