Messages in this thread Patch in this message | | | Date | Mon, 17 Mar 2003 22:00:45 -0500 | From | Ben Collins <> | Subject | [PATCH] increase BUS_ID_SIZE to 20 |
| |
I've tried to figure a way around this without adding back a lot of overhead, but I can't.
The reasoning, is the ieee1394 node's onyl way of a real unique identifier is the EUI (the 64bit GUID). It's represented as a 16 digit hex. However, each node additionally ca have unit directories.
Note that an ieee1394's node-id can change with each bus reset. The software has no control of this. So I cannot use the node-id as a unique identifier since the driver model has no way to rename a device once it has been registered. A bus reset should not require unregister/register for devices which did not change.
So, I want to use the format of "%016Lx" and "%016Lx-%d" for the formats of the bus ID in ieee1394. The second format would be used for unit directories of a node. However, current bus-id limit is 16 characters. The increase to 20 would give me 16 for the hex EUI, -, and 2 digits for the unit directories (I don't think it's even possible to have > 100 unit directories).
I looked at keeping an internal ID for the node internally, but that is just way too much overhead in our underlying system. As it is now, a driver can reference the GUID, which will never change, not even if the node moves to another bus, on a seperate physical ieee1394 card.
Please consider applying this patch.
-- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
--- linux-2.5.65.orig/include/linux/device.h 2003-03-17 19:16:02.000000000 -0500 +++ linux-2.5.65/include/linux/device.h 2003-03-17 21:50:05.000000000 -0500 @@ -35,7 +35,7 @@ #define DEVICE_NAME_SIZE 50 #define DEVICE_NAME_HALF __stringify(20) /* Less than half to accommodate slop */ #define DEVICE_ID_SIZE 32 -#define BUS_ID_SIZE 16 +#define BUS_ID_SIZE 20 enum { - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |