* Re: [PATCH] input hotplug support
2003-08-01 21:39 [PATCH] input hotplug support Andrey Borzenkov
@ 2003-08-01 23:57 ` Greg KH
2003-08-02 8:53 ` Andrey Borzenkov
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2003-08-01 23:57 UTC (permalink / raw)
To: linux-hotplug
On Sat, Aug 02, 2003 at 01:39:37AM +0400, Andrey Borzenkov wrote:
> this adds input agent and coldplug rc script. It relies on patch for
> module-init-tools that gnerates input handlers map table being posted to lkml
> as well.
>
> input agent loads input handler in respond to input subsystem request. It is
> currently purely table-driven, no attempt to provide for any static list or
> like was done, it needs some operational experience.
>
> static coldplug rc script is intended to load input handlers for any built-in
> input drivers, like e.g. psmouse (if you built it in). Currently it does it
> by parsing /proc/bus/input/devices, I'd like to use sysfs but apparently
> support for it in input susbsystem is incomplete at best.
>
> It also modifies usb.agent to not consult usb.handmap on 2.6, as it is not
> needed anymore.
>
> Patch is against 2003_05_01 version of hotplug. Comments appreciated.
Can you send it not compressed so we have a chance to read it?
thanks,
greg k-h
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] input hotplug support
2003-08-01 21:39 [PATCH] input hotplug support Andrey Borzenkov
2003-08-01 23:57 ` Greg KH
@ 2003-08-02 8:53 ` Andrey Borzenkov
2003-10-13 23:56 ` Greg KH
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Andrey Borzenkov @ 2003-08-02 8:53 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]
On Saturday 02 August 2003 03:57, Greg KH wrote:
> On Sat, Aug 02, 2003 at 01:39:37AM +0400, Andrey Borzenkov wrote:
> > this adds input agent and coldplug rc script. It relies on patch for
> > module-init-tools that gnerates input handlers map table being posted to
> > lkml as well.
> >
> > input agent loads input handler in respond to input subsystem request. It
> > is currently purely table-driven, no attempt to provide for any static
> > list or like was done, it needs some operational experience.
> >
> > static coldplug rc script is intended to load input handlers for any
> > built-in input drivers, like e.g. psmouse (if you built it in). Currently
> > it does it by parsing /proc/bus/input/devices, I'd like to use sysfs but
> > apparently support for it in input susbsystem is incomplete at best.
> >
> > It also modifies usb.agent to not consult usb.handmap on 2.6, as it is
> > not needed anymore.
> >
> > Patch is against 2003_05_01 version of hotplug. Comments appreciated.
>
> Can you send it not compressed so we have a chance to read it?
>
sorry.
plain text attached.
-andrey
[-- Attachment #2: hotplug-2003_05_01-input.patch --]
[-- Type: text/x-diff, Size: 11655 bytes --]
--- hotplug-2003_05_01/etc/hotplug/input.agent.input 2003-08-01 00:02:37.000000000 +0400
+++ hotplug-2003_05_01/etc/hotplug/input.agent 2003-08-01 15:01:46.000000000 +0400
@@ -0,0 +1,316 @@
+#!/bin/bash
+#
+# input-specific hotplug policy agent.
+#
+# This should handle 2.6.* input hotplugging,
+# with a consistent framework for adding device and driver
+# specific handling.
+#
+# Normally, adding a input device will modprobe handler(s) for
+# this device.
+#
+# Kernel input hotplug params include (not all of them may be available):
+#
+# ACTION=%s [add or remove]
+# PRODUCT=%x/%x/%x/%x
+# NAME=%s
+# PHYS=%s
+# EV=%lx
+# KEY=%lx %lx ...
+# REL=%lx
+# ABS=%lx %lx ...
+# MSC=%lx
+# LED=%lx
+# SND=%lx
+# FF=%lx %lx ...
+#
+# HISTORY:
+#
+# 30-Jul-2003 initial version
+#
+
+cd /etc/hotplug
+. hotplug.functions
+# DEBUG=yes export DEBUG
+
+# generated by module-init-tools
+MAP_CURRENT=$MODULE_DIR/modules.inputmap
+
+# accumulates list of modules we may care about
+DRIVERS=""
+
+if [ "$ACTION" = "" ]; then
+ mesg Bad INPUT agent invocation, no action
+ exit 1
+fi
+
+# we can't "unset IFS" on bash1, so save a copy
+DEFAULT_IFS="$IFS"
+
+#
+# Each modules.inputmap format line corresponds to one entry in a
+# MODULE_DEVICE_TABLE(input,...) declaration in a kernel file.
+#
+declare -i matchBits=0
+declare -i i_bustype=0 i_vendor=0 i_product=0 i_version=0
+declare -i i_evBits=0
+declare i_keyBits i_relBits i_absBits i_mscBits i_ledBits i_sndBits i_ffBits
+
+input_join_words ()
+{
+ declare name=$1 array=$2 tmp
+ if [ "$array" = '' ]; then
+ return
+ fi
+
+ set $array
+
+ tmp=$1
+ shift
+ while [ "$#" -gt 0 ]; do
+ tmp="$tmp:$1"
+ shift
+ done
+
+ eval "$name=\"$tmp\""
+}
+
+input_convert_vars ()
+{
+ if [ "$PRODUCT" != "" ]; then
+ IFS=/
+ set $PRODUCT ''
+ IFS="$DEFAULT_IFS"
+ i_bustype=0x$1
+ i_vendor=0x$2
+ i_product=0x$3
+ i_version=0x$4
+ fi
+
+ if [ "$EV" != "" ]; then
+ i_evBits=0x$EV
+ fi
+
+ input_join_words i_keyBits "$KEY"
+ input_join_words i_relBits "$REL"
+ input_join_words i_absBits "$ABS"
+ input_join_words i_mscBits "$MSC"
+ input_join_words i_ledBits "$LED"
+ input_join_words i_sndBits "$SND"
+ input_join_words i_ffBits "$FF"
+}
+
+declare -i INPUT_DEVICE_ID_MATCH_BUS=1
+declare -i INPUT_DEVICE_ID_MATCH_VENDOR=2
+declare -i INPUT_DEVICE_ID_MATCH_PRODUCT=4
+declare -i INPUT_DEVICE_ID_MATCH_VERSION=8
+declare -i INPUT_DEVICE_ID_MATCH_EVBIT=0x010
+declare -i INPUT_DEVICE_ID_MATCH_KEYBIT=0x020
+declare -i INPUT_DEVICE_ID_MATCH_RELBIT=0x040
+declare -i INPUT_DEVICE_ID_MATCH_ABSBIT=0x080
+declare -i INPUT_DEVICE_ID_MATCH_MSCBIT=0x100
+declare -i INPUT_DEVICE_ID_MATCH_LEDBIT=0x200
+declare -i INPUT_DEVICE_ID_MATCH_SNDBIT=0x400
+declare -i INPUT_DEVICE_ID_MATCH_FFBIT=0x800
+
+
+input_match_bits ()
+{
+ declare mod_bits=$1 dev_bits=$2
+ declare -i mword dword
+
+ mword=0x${mod_bits##*:}
+ dword=0x${dev_bits##*:}
+
+ while true; do
+ if [ $(( $mword & $dword != $mword )) -eq 1 ]; then
+ return 1
+ fi
+
+ mod_bits=${mod_bits%:*}
+ dev_bits=${dev_bits%:*}
+
+ case "$mod_bits-$dev_bits" in
+ *:*-*:* )
+ : continue
+ ;;
+ *:*-*|*-*:* )
+ return 0
+ ;;
+ * )
+ return 1
+ ;;
+ esac
+ done
+}
+
+#
+# stdin is "modules.inputmap" syntax
+# on return, all matching modules were added to $DRIVERS
+#
+input_map_modules ()
+{
+ local line module
+ declare -i matchBits
+ declare -i bustype vendor product version
+ declare -i evBits driverInfo
+ declare relBits mscBits ledBits sndBitskeyBits absBits ffBits
+
+ while read line
+ do
+ # comments are lines that start with "#" ...
+ # be careful, they still get parsed by bash!
+ case "$line" in
+ \#*) continue ;;
+ esac
+
+ set $line
+
+ module="$1"
+ matchBits="$2"
+
+ bustype="$3"
+ vendor="$4"
+ product="$5"
+ product="$6"
+
+ evBits="$7"
+ keyBits="$8"
+ relBits="$9"
+
+ shift 9
+ absBits="$1"
+ cbsBits="$2"
+ ledBits="$3"
+ sndBits="$4"
+ ffBits="$5"
+ driverInfo="$6"
+
+ : checkmatch $module
+
+ : bustype $bustype $i_bustype
+ if [ $INPUT_DEVICE_ID_MATCH_BUS -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_BUS )) ] &&
+ [ $bustype -ne $i_bustype ]; then
+ continue
+ fi
+
+ : vendor $vendor $i_vendor
+ if [ $INPUT_DEVICE_ID_MATCH_VENDOR -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_VENDOR )) ] &&
+ [ $vendor -ne $i_vendor ]; then
+ continue
+ fi
+
+ : product $product $i_product
+ if [ $INPUT_DEVICE_ID_MATCH_PRODUCT -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_PRODUCT )) ] &&
+ [ $product -ne $i_product ]; then
+ continue
+ fi
+
+ # version i_version $i_version < version $version
+ if [ $INPUT_DEVICE_ID_MATCH_VERSION -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_VERSION )) ] &&
+ [ $version -ge $i_version ]; then
+ continue
+ fi
+
+ : evBits $evBits $i_evBits
+ if [ $INPUT_DEVICE_ID_MATCH_EVBIT -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_EVBIT )) ] &&
+ [ $evBits -ne $(( $evBits & $i_evBits)) ]; then
+ continue
+ fi
+ : keyBits $keyBits $i_keyBits
+ if [ $INPUT_DEVICE_ID_MATCH_KEYBIT -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_KEYBIT )) ] &&
+ input_match_bits "$keyBits" "$i_keyBits"; then
+ continue
+ fi
+ : relBits $relBits $i_relBits
+ if [ $INPUT_DEVICE_ID_MATCH_RELBIT -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_RELBIT )) ] &&
+ [ $relBits -ne $(( $relBits & $i_relBits)) ]; then
+ continue
+ fi
+
+ : absBits $absBits $i_absBits
+ if [ $INPUT_DEVICE_ID_MATCH_ABSBIT -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_ABSBIT )) ] &&
+ input_match_bits "$absBits" "$i_absBits"; then
+ continue
+ fi
+
+ : mscBits $mscBits $i_mscBits
+ if [ $INPUT_DEVICE_ID_MATCH_MSCBIT -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_MSCBIT )) ] &&
+ [ $mscBits -ne $(( $mscBits & $i_mscBits)) ]; then
+ continue
+ fi
+
+ : ledBits $ledBits $_ledBits
+ if [ $INPUT_DEVICE_ID_MATCH_LEDBIT -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_LEDBIT )) ] &&
+ input_match_bits "$ledBits" "$i_ledBits"; then
+ continue
+ fi
+
+ : sndBits $sndBits $i_sndBits
+ if [ $INPUT_DEVICE_ID_MATCH_SNDBIT -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_SNDBIT )) ] &&
+ [ $sndBits -ne $(( $sndBits & $i_sndBits)) ]; then
+ continue
+ fi
+
+ : ffBits $ffBits $i_ffBits
+ if [ $INPUT_DEVICE_ID_MATCH_FFBIT -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_FFBIT )) ] &&
+ input_match_bits "$ffBits" "$i_ffBits"; then
+ continue
+ fi
+
+ : driverInfo $driverInfo
+ if [ $matchBits -eq 0 -a $driverInfo -eq 0 ]; then
+ continue
+ fi
+
+ # It was a match!
+ case " $DRIVERS " in
+ *" $module "* )
+ : already found
+ ;;
+ * )
+ DRIVERS="$module $DRIVERS"
+ ;;
+ esac
+ : drivers $DRIVERS
+ done
+}
+
+#
+# What to do with this INPUT hotplug event?
+#
+case $ACTION in
+
+add)
+
+ input_convert_vars
+
+ FOUND=false
+ LABEL="INPUT product $PRODUCT"
+
+ if [ -r $MAP_CURRENT ]; then
+ load_drivers input $MAP_CURRENT "$LABEL"
+ fi
+
+ if [ "$DRIVERS" != "" ]; then
+ FOUND=true
+ fi
+
+ if [ "$FOUND" = "false" ]; then
+ mesg "... no modules for $LABEL"
+ exit 2
+ fi
+
+ ;;
+
+remove)
+ : nothing so far
+
+ ;;
+
+*)
+ debug_mesg INPUT $ACTION event not supported
+ exit 1
+ ;;
+
+esac
--- hotplug-2003_05_01/etc/hotplug/input.rc.input 2003-08-01 15:02:09.000000000 +0400
+++ hotplug-2003_05_01/etc/hotplug/input.rc 2003-08-01 15:02:13.000000000 +0400
@@ -0,0 +1,147 @@
+#!/bin/bash
+#
+# input.rc This loads handlers for those input devices
+# that have drivers compiled in kernel
+# Currently stopping is not supported
+#
+# Best invoked via /etc/init.d/hotplug or equivalent, with
+# writable /tmp, /usr mounted, and syslogging active.
+#
+
+
+PATH=/sbin:/bin:/usr/sbin:/usr/bin
+PROCDIR=/proc/bus/input
+
+# source function library
+if [ -f /etc/init.d/functions ]; then
+ . /etc/init.d/functions
+elif [ -f /etc/rc.d/init.d/functions ]; then
+ . /etc/rc.d/init.d/functions
+fi
+
+if [ -f /etc/hotplug/hotplug.functions ]; then
+ . /etc/hotplug/hotplug.functions
+fi
+
+input_reset_state () {
+
+ PRODUCT=
+ NAME=
+ PHYS=
+ EV=
+ KEY=
+ REL=
+ ABS=
+ MSC=
+ LED=
+ SND=
+ FF=
+
+}
+
+#
+# "COLD PLUG" ... load input handlers for compile-in input drivers loaded
+# before the OS could really handle hotplug, perhaps because /sbin or
+# $HOTPLUG_DIR wasn't available or /tmp wasn't writable. When/if the
+# /sbin/hotplug program is invoked then, hotplug event notifications
+# get dropped. To make up for such "cold boot" errors, we synthesize
+# all the hotplug events we expect to have seen already. They can be
+# out of order, and some might be duplicates.
+#
+input_boot_events ()
+{
+ if [ ! -r $PROCDIR/devices ]; then
+ echo $"** can't synthesize input events - $PROCDIR/devices missing"
+ return
+ fi
+
+ ACTION=add
+ export ACTION
+
+ export PRODUCT NAME PHYS EV KEY REL ABS MSC LED SND FF
+ input_reset_state
+
+ declare line
+
+ #
+ # the following reads from /proc/bus/input/devices. It is inherently
+ # racy (esp. as this file may be changed by input.agent invocation)
+ # but so far input devices do not appear in sysfs
+ #
+ while read line; do
+ case "$line" in
+ I:* ) # product ID
+ eval "${line#I: }"
+ PRODUCT=$Bus/$Vendor/$Product/$Version
+ ;;
+ N:* ) # name
+ eval "${line#N: }"
+ NAME="$Name"
+ ;;
+ P:* ) # Physical
+ eval "${line#P: }"
+ PHYS=$Phys
+ ;;
+ B:* ) # Controls supported
+ line="${line#B: }"
+ eval "${line%%=*}=\"${line#*=}\""
+ ;;
+ "" ) # End of block
+ debug_mesg "Invoking input.agent"
+ debug_mesg "PRODUCT=$PRODUCT"
+ debug_mesg "NAME=$NAME"
+ debug_mesg "PHYS=$PHYS"
+ debug_mesg "EV=$EV"
+ debug_mesg "KEY=$KEY"
+ debug_mesg "REL=$REL"
+ debug_mesg "ABS=$ABS"
+ debug_mesg "MSC=$MSC"
+ debug_mesg "LED=$LED"
+ debug_mesg "SND=$SND"
+ debug_mesg "FF=$FF"
+ /etc/hotplug/input.agent < /dev/null
+ input_reset_state
+ ;;
+ esac
+ done < $PROCDIR/devices
+}
+
+
+# See how we were called.
+case "$1" in
+ start)
+ input_boot_events
+ ;;
+ stop)
+ : not supported currently
+ ;;
+ status)
+ echo $"INPUT status for kernel: " `uname -srm`
+ echo ''
+
+ echo "INPUT devices:"
+ if [ -r $PROCDIR/devices ]; then
+ grep "^[INHP]:" $PROCDIR/devices
+ else
+ echo "$PROCDIR/devices not available"
+ fi
+ echo ''
+
+ echo "INPUT handlers:"
+ if [ -r $PROCDIR/handlers ]; then
+ cat $PROCDIR/handlers
+ else
+ echo "$PROCDIR/handlers not available"
+ fi
+
+ echo ''
+
+ ;;
+ restart)
+ # always invoke by absolute path, else PATH=$PATH:
+ $0 stop && $0 start
+ ;;
+ *)
+ echo $"Usage: $0 {start|stop|status|restart}"
+ exit 1
+esac
--- hotplug-2003_05_01/etc/hotplug/usb.agent.input 2003-08-01 00:02:37.000000000 +0400
+++ hotplug-2003_05_01/etc/hotplug/usb.agent 2003-08-01 00:02:37.000000000 +0400
@@ -397,12 +397,20 @@
# cope with special driver module configurations
# (mostly HID devices, until we have an input.agent)
- if [ -r $MAP_HANDMAP ]; then
- load_drivers usb $MAP_HANDMAP "$LABEL"
- if [ "$DRIVERS" != "" ]; then
- FOUND=true
- fi
- fi
+ # not needed on 2.6 - they are loaded by hotplug
+ case "$KERNEL" in
+ 2.6.* )
+ : nothing
+ ;;
+ * )
+ if [ -r $MAP_HANDMAP ]; then
+ load_drivers usb $MAP_HANDMAP "$LABEL"
+ if [ "$DRIVERS" != "" ]; then
+ FOUND=true
+ fi
+ fi
+ ;;
+ esac
# some devices have user-mode drivers (no kernel module, but config)
# or specialized user-mode setup helpers
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] input hotplug support
2003-08-01 21:39 [PATCH] input hotplug support Andrey Borzenkov
2003-08-01 23:57 ` Greg KH
2003-08-02 8:53 ` Andrey Borzenkov
@ 2003-10-13 23:56 ` Greg KH
2003-10-28 18:19 ` Andrey Borzenkov
2003-10-29 0:15 ` Rusty Russell
4 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2003-10-13 23:56 UTC (permalink / raw)
To: linux-hotplug
On Sat, Aug 02, 2003 at 12:53:02PM +0400, Andrey Borzenkov wrote:
> On Saturday 02 August 2003 03:57, Greg KH wrote:
> > On Sat, Aug 02, 2003 at 01:39:37AM +0400, Andrey Borzenkov wrote:
> > > this adds input agent and coldplug rc script. It relies on patch for
> > > module-init-tools that gnerates input handlers map table being posted to
> > > lkml as well.
> > >
> > > input agent loads input handler in respond to input subsystem request. It
> > > is currently purely table-driven, no attempt to provide for any static
> > > list or like was done, it needs some operational experience.
> > >
> > > static coldplug rc script is intended to load input handlers for any
> > > built-in input drivers, like e.g. psmouse (if you built it in). Currently
> > > it does it by parsing /proc/bus/input/devices, I'd like to use sysfs but
> > > apparently support for it in input susbsystem is incomplete at best.
> > >
> > > It also modifies usb.agent to not consult usb.handmap on 2.6, as it is
> > > not needed anymore.
> > >
> > > Patch is against 2003_05_01 version of hotplug. Comments appreciated.
> >
> > Can you send it not compressed so we have a chance to read it?
>
> sorry.
>
> plain text attached.
Thanks, I've applied this patch. Did your module-init-tools patch make
it into that package too?
thanks,
greg k-h
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] input hotplug support
2003-08-01 21:39 [PATCH] input hotplug support Andrey Borzenkov
` (2 preceding siblings ...)
2003-10-13 23:56 ` Greg KH
@ 2003-10-28 18:19 ` Andrey Borzenkov
2003-10-29 0:15 ` Rusty Russell
4 siblings, 0 replies; 6+ messages in thread
From: Andrey Borzenkov @ 2003-10-28 18:19 UTC (permalink / raw)
To: linux-hotplug
On Tuesday 14 October 2003 03:56, Greg KH wrote:
> On Sat, Aug 02, 2003 at 12:53:02PM +0400, Andrey Borzenkov wrote:
> > On Saturday 02 August 2003 03:57, Greg KH wrote:
> > > On Sat, Aug 02, 2003 at 01:39:37AM +0400, Andrey Borzenkov wrote:
> > > > this adds input agent and coldplug rc script. It relies on patch for
> > > > module-init-tools that gnerates input handlers map table being posted
> > > > to lkml as well.
> > > >
> > > > input agent loads input handler in respond to input subsystem
> > > > request. It is currently purely table-driven, no attempt to provide
> > > > for any static list or like was done, it needs some operational
> > > > experience.
> > > >
> > > > static coldplug rc script is intended to load input handlers for any
> > > > built-in input drivers, like e.g. psmouse (if you built it in).
> > > > Currently it does it by parsing /proc/bus/input/devices, I'd like to
> > > > use sysfs but apparently support for it in input susbsystem is
> > > > incomplete at best.
> > > >
> > > > It also modifies usb.agent to not consult usb.handmap on 2.6, as it
> > > > is not needed anymore.
> > > >
> > > > Patch is against 2003_05_01 version of hotplug. Comments appreciated.
> > >
> > > Can you send it not compressed so we have a chance to read it?
> >
> > sorry.
> >
> > plain text attached.
>
> Thanks, I've applied this patch. Did your module-init-tools patch make
> it into that package too?
>
No, Rusty was against it. You should have received those mails as well (you
were on Cc at least), subject was
"module-init-tools - input devices id support"
If you do not have them I can forward or they are on lkml as well, sorry do
not have pointers handy.
in short Rusty said the right thing is to use scripts/file2alias to generate
module aliases out of input device id tables. While I do not object in
principle, the reasons I did it the current way were
- it is consistent with how things are implemented currently and no one so far
told me it is going to change
- I think it is more flexible. E.g. it provides for extra filtering
(blacklisting) if needed. Doing this requires most of the current code (in
some form) even in presence of aliases generated by file2alias
- given size of input id tables it will generate aliases of size more than 1k
characters. Not that I really care but it is hardly readable.
- file2alias works only at kernel compile time. Users are free to install
extra (binary) modules at any time and expect them to still be recognized.
I really think that keeping module-init-tools in sync with kernel is not much
more difficult than keeping file2alias in sync with kernel. Whoever neglects
update the former may just as well neglect to update the latter. And so far
this was the main argument of Rusty IIRC.
cheers
and sorry for delay too
-andrey
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] input hotplug support
2003-08-01 21:39 [PATCH] input hotplug support Andrey Borzenkov
` (3 preceding siblings ...)
2003-10-28 18:19 ` Andrey Borzenkov
@ 2003-10-29 0:15 ` Rusty Russell
4 siblings, 0 replies; 6+ messages in thread
From: Rusty Russell @ 2003-10-29 0:15 UTC (permalink / raw)
To: linux-hotplug
In message <200310282119.01702.arvidjaar@mail.ru> you write:
> > Thanks, I've applied this patch. Did your module-init-tools patch make
> > it into that package too?
>
> No, Rusty was against it. You should have received those mails as well (you
> were on Cc at least), subject was
>
> "module-init-tools - input devices id support"
Let's go through this again.
1) I don't understand what you want. eg. for USB devices, they're
used to match the USB device to the USB driver for autoloading.
You seemed surprised when I suggested you could autoload the input
drivers: but what else would you want this information for?
2) While a naive approach to aliases would make aliases for input
drivers about 1000 chars long, that's just a good reason not to use
a naive approach. I already suggested one approach based on the
looking at the current drivers in the tree.
3) Since we're talking about 5 drivers in all, you could simply
hardcode them if this is all too much trouble for you.
4) You *have* been informed that this is changing, months ago. As
soon as Greg tells me that hotplug scripts no longer need those
tables, they will be removed in favour of the aliases which exist.
5) If you want some tables for other reasons, there's no reason for
you not to generate them yourself. Experience has shown that this
method is fragile, but that's your choice.
6) You're confused about external modules: the module supplier runs
file2alias as part of the build process, the user runs depmod as
normal, so no problems.
> I really think that keeping module-init-tools in sync with kernel is not much
> more difficult than keeping file2alias in sync with kernel.
But they are *distributed separately*, so for the end user, it's much
harder to keep them in sync. That's been one of the main aims of the
new module code: kernel independence.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 6+ messages in thread