[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support



Giacomo Catenazzi wrote:
> 
> Michael Biebl wrote:
>> Giacomo A. Catenazzi wrote:
>>> Michael Biebl wrote:
>>>> Roger Leigh wrote:
>>>>> On Mon, Apr 20, 2009 at 05:52:41PM +0200, Michael Biebl wrote:
>>>>>> Roger Leigh wrote:
>>>>>>
>>>>>>> On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote:
>>>>>>>> hal does not poll removable disks, it does though poll cd-rom drives for new
>>>>>>>> media and afaik there is no way around that if you want automount for cdrom
>>>>>>>> drives to work
>>>>>>> Spinning up the CD drive every 30 seconds is simply not an acceptable
>>>>>>> "solution".  If that's the best HAL can do, it should be disabled by
>>>>>>> default, and users will simply have to select the device by hand; we're
>>>>>>> only talking about automatic mounting here, after all.
>>>>>> First, polling the cd drive for new media should not spin it up. If it does it
>>>>>> is most likely a kernel/driver or firmware bug.
>>>>> So the bug is in a kernel driver, possibly.  But, it's still hal
>>>>> triggering the bug by the continual polling.
>>>>>
>>>>>> Second, you can very easily disable this behaviour: man hal-disable-polling
>>>>> Great, but it's still not the default behaviour.  Does every
>>>>> user need to find out how to disable it after they become sufficiently
>>>>> annoyed by the constant spinning up of their CD drive?
>>>> Why should *every* user need to find out? Seems to me as if you are exaggerating
>>>> in order to make a point. For the majority of users it just works, that's why it
>>>> is the default.
>>> powertop encourages to disable polling, so it is a big point.
>> I agree with you in general, but I doubt polling every 2 or 16 seconds will make
>> any significant difference power consumption wise.
> 
> 
> Recently it was discovered that a blinking cursor consumes a lot of power
> (blink is normally between 1 and 2 second interval).
> I think it should be the same, in this case.
> Take into account that both uses hardware, thus not allowing some chips
> to rests.
> 
> I've no machine (maybe misconfiguration) with powertop indicating
> the power demand.  Could someone do some tests?
> (hal-disable-polling has the option also to enable the pooling)

It makes no measurable difference here on my laptop (nx7000) running Debian Lenny.

>>> "Majority of users it just works", but how many of such user will use this feature?
>> How shall I answer that?
>> I know that I myself use auto-mounting extensively and also don't expect my
>> father to type someting like "mount /dev/hdc /mnt/cdrom"
> 
> On the other side, it was considered a bad idea for the security standpoint.
> [Remember also the "audio CD" with also some data (and maybe the famous
> old windoze rootkit.  Which kind of CD is recognized? Could user recognize
> from CD which action will be done?]

I think what you are referring too, is the so-called autorun feature of windows.
I need to clarify here, that hal itself does *not* do the automounting itself.
It merely provides the information when a media is inserted or not.
The desktop environment (or tools like volman) listen to those events and
trigger the actual mounting.

This way, you can very easily configure within the desktop environment, which
kind of policy/actions you want have (see e.g. gnome-volume-manager).

Also, afaik none of the big desktop environments starts any scripts on a
removable media without asking you first.

> IMHO the right thing to do is "automount", when people try to access the
> right directory (filemanager, open dialog windoze, ...).

Correct, that's up to the user to decide. But for that to work correctly, the
need the information provided by hal.

Just wanted to clarify that, as there seem to be some misconceptions about hal
even if it has become completely OT.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: