linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* udev - keep private data out of the database?
@ 2004-02-12 17:09 Kay Sievers
  2004-02-12 23:13 ` Greg KH
  0 siblings, 1 reply; 2+ messages in thread
From: Kay Sievers @ 2004-02-12 17:09 UTC (permalink / raw)
  To: linux-hotplug

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

Shouldn't we keep the temporary strings out of the database,
or is this information useful for something?

It cuts the length of the data from 628 to 275 bytes.

And shouldn't we add a 'rm /udev/.udevdb' to the init scripts?
Without it, we can't change the format of the records, cause udev
refuses to work with the old file.

thanks,
Kay

[-- Attachment #2: 01-keep-private-strings-out-of-db.patch --]
[-- Type: text/plain, Size: 1602 bytes --]

===== udev.h 1.38 vs edited =====
--- 1.38/udev.h	Thu Feb 12 02:29:39 2004
+++ edited/udev.h	Thu Feb 12 17:41:58 2004
@@ -24,6 +24,7 @@
 #define UDEV_H
 
 #include "libsysfs/libsysfs.h"
+#include <stddef.h>
 #include <sys/param.h>
 
 #define COMMENT_CHARACTER		'#'
@@ -33,6 +34,9 @@
 #define GROUP_SIZE	30
 #define MODE_SIZE	8
 
+/* length of public data */
+#define UDEVICE_LEN (offsetof(struct udevice, bus_id))
+
 struct udevice {
 	char name[NAME_SIZE];
 	char owner[OWNER_SIZE];
@@ -43,11 +47,11 @@
 	unsigned int mode;	/* not mode_t due to conflicting definitions in different libcs */
 	char symlink[NAME_SIZE];
 
-	/* fields that help us in building strings */
-	unsigned char bus_id[SYSFS_NAME_LEN];
-	unsigned char program_result[NAME_SIZE];
-	unsigned char kernel_number[NAME_SIZE];
-	unsigned char kernel_name[NAME_SIZE];
+	/* private data that help us in building strings */
+	char bus_id[SYSFS_NAME_LEN];
+	char program_result[NAME_SIZE];
+	char kernel_number[NAME_SIZE];
+	char kernel_name[NAME_SIZE];
 };
 
 #define strfieldcpy(to, from) \
===== udevdb.c 1.19 vs edited =====
--- 1.19/udevdb.c	Sat Jan 17 15:47:18 2004
+++ edited/udevdb.c	Thu Feb 12 17:46:14 2004
@@ -58,8 +58,8 @@
 	key.dsize = strlen(keystr) + 1;
 
 	data.dptr = (void *)dev;
-	data.dsize = sizeof(*dev);
-	
+	data.dsize = UDEVICE_LEN;
+
 	return tdb_store(udevdb, key, data, TDB_REPLACE); 
 }
 
@@ -77,7 +77,8 @@
 	if (data.dptr == NULL || data.dsize == 0)
 		return -ENODEV;
 
-	memcpy(dev, data.dptr, sizeof(*dev));
+	memset(dev, 0, sizeof(struct udevice));
+	memcpy(dev, data.dptr, UDEVICE_LEN);
 	return 0;
 }
 

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: udev - keep private data out of the database?
  2004-02-12 17:09 udev - keep private data out of the database? Kay Sievers
@ 2004-02-12 23:13 ` Greg KH
  0 siblings, 0 replies; 2+ messages in thread
From: Greg KH @ 2004-02-12 23:13 UTC (permalink / raw)
  To: linux-hotplug

On Thu, Feb 12, 2004 at 06:09:17PM +0100, Kay Sievers wrote:
> Shouldn't we keep the temporary strings out of the database,
> or is this information useful for something?
> 
> It cuts the length of the data from 628 to 275 bytes.

Nice, applied.

> And shouldn't we add a 'rm /udev/.udevdb' to the init scripts?
> Without it, we can't change the format of the records, cause udev
> refuses to work with the old file.

Good point.  I'll go add that.

thanks,

greg k-h


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
_______________________________________________
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] 2+ messages in thread

end of thread, other threads:[~2004-02-12 23:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-02-12 17:09 udev - keep private data out of the database? Kay Sievers
2004-02-12 23:13 ` Greg KH

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).