make_dev & cdevsw_add (Is there anyone that could answer this ?)
Hello (again)! I would kindly request explanation on how are cdevsw_add and make_dev related ? Maybe short example also with focus on cdevsw_add. Thing is i do not understand the function of cdevsw_add when i have make_dev. Also if there is any real good document that describes most of cdev related stuff i would appriciate if someone gives me an url. Second thing that i would like to know is: struct cdevsw { d_open_t*d_open; When a process calls open on character device and d_open function is called would it be possible to determine the file descriptor returned by the open system call on that device that is returned to the process from d_open ? That is i would like to implement character device that wouldn't require /dev/somedev[0-9]+ number of devices but only /dev/somedev and would identify the open/close/ read/write operations by pid and fd instead of dev_t's minor number. re RP ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
make_dev & cdevsw_add
Hello! I would kindly request explanation on how are cdevsw_add and make_dev related ? Maybe short example also with focus on cdevsw_add. Thing is i do not understand the function of cdevsw_add when i have make_dev. Also if there is any real good document that describes most of cdev related stuff i would appriciate if someone gives me an url. Second thing that i would like to know is: struct cdevsw { d_open_t*d_open; When a process calls open on character device and d_open function is called would it be possible to determine the file descriptor returned by the open system call on that device that is returned to the process from d_open ? That is i would like to implement character device that wouldn't require /dev/somedev[0-9]+ number of devices but only /dev/somedev and would identify the open/close/ read/write operations by pid and fd instead of dev_t's minor number. re RP ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cdevsw_add
Basically I'm not working on devfs at the moment since the bit that made it workable was ripped out with extreme prejudice by someone. I'm still absolutly convinced that a dynamic device registration and export framework is required in the long run, but I'm not fussed if it's based on the current devfs or an successor. I'd feel a bit happier about spending more time on it If I had any thought that the result would not be ripped out by the throat as soon as it works again, by a maniac that doesn't understand that it's a working subsystem (it was fully working at the time it was vandaliased but the nice fellow didn't even try it, and I got no warning except the commit message). There were two known problems that were based in other parts of the code (mfs and some vfs/module stuff) And the install software couldn't install with it. If PHK is working an a framework to make this easier, I'd love to get a white-paper on the topic because it's all unknown stuff at the moment. To get it going, you basically need to reverse the backout commits done by SOS a year ago. DEVSF itself works, but it needs a different disk subsystem to be able to represent dynamic disk partitions properly. julian On Sat, 5 Jun 1999, Nick Hibma wrote: > > >While on the topic: Who is working on devfs and why not? > > > > I'm not currently working on devfs, but I am building the infrastructure > > it should be based on in the kernel. > > Anymore information available on where you are with this? > > Cheers, > > Nick > > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cdevsw_add
On Sat, 5 Jun 1999, Poul-Henning Kamp wrote: > In message , Nick Hibma > writes: > > > >While on the topic: Who is working on devfs and why not? > > > > > > I'm not currently working on devfs, but I am building the infrastructure > > > it should be based on in the kernel. > > > >Anymore information available on where you are with this? > > I currently have a kernel running where dev_t is a pointer to a > "struct dev" and where char and block devs are collapsed at the > dev_t level. There are some bogons i need to fumigate, but I'm > off to give a course in Stockholm much of this coming week, so > don't expect any commits just now. (I may actually postpone/abandon > this step for now, since some of the changes pulls rugs away which > cover what looks to me like holes in the floor). > > Next is to integrate the dev_t anti-aliasing and vnode anti-aliasing > code. > > When I have that bit down and done, the next step is for device > drivers to register individual dev_t's rather than blanket cdevsw > entries. The later ability will be retained for pseudo drivers > and other (pseudo)magic. > > This registration will look pretty much like the current #ifdef'ed > DEVFS stuff, and in addition it will allow the driver to hang two > fields of the dev_t, typically a pointer to the struct softc and > maybe a unit number or something. This will obsolete all of > the magic minor -> {unit|softc} converters in our drivers and > make the "NFOO" configuration obsolete. > > That is, as such the end of this little project, and where a future > DEVFS could take off from. Basically all that is needed for a DEVFS > to do, is to hook into the dev_t maintenance code and construct > the directory tree. DEVFS has always meant to do exactly this. there is already a place in the structure for these two fields, and when devfs is running, the devsw[] table is not consulted. The vnode already contains a direct pointer to the devsw entry and a cookie (minor number), and these are called directly. there is already a node type for the 'unified' device type. there are three types of device in devfs BDEV, CDEV and DDEV. DDEV has only a pointer to teh methods and a cookie. (as you suggest above) > > -- > Poul-Henning Kamp FreeBSD coreteam member > p...@freebsd.org "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cdevsw_add
In message , Nick Hibma writes: > > >While on the topic: Who is working on devfs and why not? > > > > I'm not currently working on devfs, but I am building the infrastructure > > it should be based on in the kernel. > >Anymore information available on where you are with this? I currently have a kernel running where dev_t is a pointer to a "struct dev" and where char and block devs are collapsed at the dev_t level. There are some bogons i need to fumigate, but I'm off to give a course in Stockholm much of this coming week, so don't expect any commits just now. (I may actually postpone/abandon this step for now, since some of the changes pulls rugs away which cover what looks to me like holes in the floor). Next is to integrate the dev_t anti-aliasing and vnode anti-aliasing code. When I have that bit down and done, the next step is for device drivers to register individual dev_t's rather than blanket cdevsw entries. The later ability will be retained for pseudo drivers and other (pseudo)magic. This registration will look pretty much like the current #ifdef'ed DEVFS stuff, and in addition it will allow the driver to hang two fields of the dev_t, typically a pointer to the struct softc and maybe a unit number or something. This will obsolete all of the magic minor -> {unit|softc} converters in our drivers and make the "NFOO" configuration obsolete. That is, as such the end of this little project, and where a future DEVFS could take off from. Basically all that is needed for a DEVFS to do, is to hook into the dev_t maintenance code and construct the directory tree. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cdevsw_add
> >While on the topic: Who is working on devfs and why not? > > I'm not currently working on devfs, but I am building the infrastructure > it should be based on in the kernel. Anymore information available on where you are with this? Cheers, Nick To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cdevsw_add
In message , Nick Hibma writes: > >While on the topic: Who is working on devfs and why not? > >I'd like to know whether there is some interest in getting that work >underway again. More than interested to help. I'm not currently working on devfs, but I am building the infrastructure it should be based on in the kernel. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cdevsw_add
While on the topic: Who is working on devfs and why not? I'd like to know whether there is some interest in getting that work underway again. More than interested to help. > You're forgetting that devsw[] is another stopgap. The kernel should > probably use something like devfs, where dev_t's only exist for devices > that actually exist. xxx_init() is far too early to decide which hardware > devices exist. > > Bruce Nick To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message