Hi geert, i suppose it would be feasible, to add an option in the beta2, to allow /dev to be sym linked to /etc/dev (for developement purposes. that way you can mknod nodes dynamically. busybox would need to configured to add the mknod(i think it is not build by default
John --- In [email protected], "Geert Vancompernolle" <[EMAIL PROTECTED]> wrote: > > Hi Ernst, > > --- In [email protected], "Ernst Mayerhofer" > <ernst.mayerhofer@> wrote: > > > > Hi, > > > > if you type "make" in the devboard directory your fimage will be > generated. > > and it's possible WITHOUT ANY STARTUP SCRIPT to insert a character > device in > > the fimage in /dev. I would suggest to use /dev because it's a > convention to > > use that directory. > > Indeed, and that's the current state of the Phrozen SDK distribution. > > >anyway you know that. instead of putting a character > > device there you put a symbolic link there. > > > > Correct, because I want to keep the "normal" location of device nodes in > /dev (but "behind the scenes" leading to -currently still- /etc/dev). > > > What you actually did is a workaround. In my mother tongue i would > call it > > simply "pfusch". > > I hope that doesn't mean b******t... ;-) > > > means that something is not designed for this purpose. > > > > Indeed, since the RFS is programmed into the RO part of the flash, > it's not very "dynamically"... > > But as I stated in one of my previous messages, I read in the LDD book > (isn't that "the Bible" for Linux device drivers?) that the tendency > is to move away from statically allocated MAJOR numbers. So, I saw it > as an opportunity and an exercise for myself to try to make a "static" > thing "dynamic". > > > I would suggest not to use a dynamic major number. You shoud instead > use a > > free major number and enter it in the file where all the mknod_elinux > > commands are. (packages/devices.../Makefile) > > > > Since I studied the wow of the whole FoxBoard make set-up, I know > where to find those things, so no problem. > And your statement is absolutely not wrong if you say to "stick" to a > static MAJOR number. > But my problem is, I'm planning to add more drivers for my own (home > automation) application and I don't want to look every time for > another MAJOR number which is still free. > I'm lazy ( ;-) ) and would like to leave this task to the kernel > himself (or herself???). > > > if you continue anyway, i would suggest using /var, because you have to > > write it maybe on every startup. the flash memory is not a hard > drive, and > > you shouldn't change it that often. > > > > Well, since I currently put it into /etc/dev, it's written only once: > each time when a new flash image is programmed. > After that, since the directory /etc/dev and the device node /i2c is > already present, the commands mkdir and mknod will simply not be executed. > Next to this, I "safeguarded" my script against that: if the directory > and/or character device already exists, then don't do anything. > > But maybe I will move it finally to the /var location. > Anyhow, it's not very important any more where the "real" node finally > resides, since I'm using a symbolic link to simulate the "normal, > official" behaviour of device node locations. And that symbolic link > is located in /dev. > So, when performing an "open" of, let's say, the I2C device driver, > then one can still continue to use "open( "/dev/i2c",...)". > This way (and that's also very important), "old" code will not break... > > > but maybe there is some better advise than mine. i am a newcomer, too. > > > > Well, I'm interested too to see if other people have other ideas about > this subject. > > Thanks a bunch, Ernst, for the time you spent in reading and answering > my questions and helping me with suggestions! > > Best rgds, > > --Geert >
