FC5 hotplug documentation?

[Karl Larsen]

Mikkel L. Ellertson wrote:
> Karl F. Larsen wrote:
>   
>> Mikkel L. Ellertson wrote:
>>     
>>> Wolfgang S. Rupprecht wrote:
>>>  
>>>       
>>>> Is there any documentation for FC5's hotplug?  I need to know the
>>>> format/location  of the action scripts that get run when a new device
>>>> gets plugged in.
>>>>
>>>> I have a usb GPS device (it looks like a serial port) that I'd like to
>>>> have recognized and have the device permissions automatically set to
>>>> allow the user access.  Doing an su to root and "chmod 666
>>>> /dev/ttyXXX" every time I plug it in is getting old.
>>>>
>>>>     
>>>>         
>>> You should look at the udev and HAL documentation. Hotplug is not
>>> really used any more. Chances are, you can do this with a udev rule,
>>> and have it create a /dev/gps symlink at the same time.
>>>
>>> Mikkel
>>>   
>>>       
>>    Hello Mikkel, I was trying to get a ham radio appliance to work in
>> FC5 and my playing around got me to UDEV and I read all the man and info
>> pages on udev and decided if it takes an understanding of this to use
>> FC5 I will go back to FC2. And that is exactly what I did.
>>
>>    By the way, you say hotplug is no longer used and it is a part of
>> EVERY thought given to UDEV and all that mysterious stuff at
>> /etc/security/*. This stuff really made me wonder what Linux is coming
>> to.  I was fat dumb and happy with Red Hat 9. I should have stayed there
>> :-)
>>
>> Karl
>>
>>     
> I know what you mean. HAL and udev are a big change. But I think it
> is worth it in the long run. For what you want, it should be a
> simple udev rule. Basicly, you would put a rule in
> /etc/udev/rules.d/10-local.rules (You may have to create it.) with
> something like:
>
> BUS="usb", SYSFS{serial}="<serial number of GPS device>",
> NAME="gps", MODE="0666"
>
> or
>
> BUS="usb", SYSFS{vendor}="<GPM vender>", SYSFS{model}="<GPS model>",
> NAME="GPS", MODE="0666"
>
>
> Note that each rule in one line - they may be wrapped by the mail
> client. You can also do things like specify the owner/group of the
> device, add things like a symlink, etc. The thing is, this rule will
> only be used if the serial number (rule 1) or vender and device
> (rule 2) match the device you are plugging in. Because of the way
> udev processes rules, the 10-local.rules is processed before the
> default rules, and the first match is used. So other USB serial
> devices are processed normally. But udev does not allow the fine
> control that HAL does. With HAL, you can do things like assign the
> ownership of the device to the owner of the console, run an
> application, etc.
>
> Think of HAL as a programming language for handling devices. The
> thing that I think holds the most promise of HAL is that you can add
> specific files for devices that will be used instead of the default
> rules. So you could see devices come with a HAL rule set, just like
> they come with device drivers for Windows. This could specify the
> device name, a program to be run, or a desktop icon to use when the
> device is attached. That way, when you bring home the GPS device,
> you would install the HAL rule, and any specific software that comes
> with it, and it would work anytime you plugged it in without you
> having to do anything. (It could all be in an RPM...)
>
> Mikkel
>   
    Hi Mikkel I am saving this message since you have explained a lot of 
new features I am not aware of. But if you can send the HAL data in an 
RPM that sounds very powerful.

    My current problem is I think part of the application. I will write 
the author with I hope enough meat that he can understand what is happening.

Karl