Re: Device cloning
On Tue, Jun 11, 2002 at 10:14:48AM -0700, Maksim Yevmenkin wrote: or USB dongle. They all MUST talk via HCI. So HCI is not really a device driver, and, IMO, it is not a pseudo device driver. It sort of looks like /dev/tcp :) Hi Maksim, A ng_device netgraph node is coming up. That will present you with a /dev/whatever you want interface to the netgraph subsystem. That might be a starting point, as your work is also a netgraph node. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
Hi Mark, On Tue, Jun 11, 2002 at 10:14:48AM -0700, Maksim Yevmenkin wrote: or USB dongle. They all MUST talk via HCI. So HCI is not really a device driver, and, IMO, it is not a pseudo device driver. It sort of looks like /dev/tcp :) A ng_device netgraph node is coming up. That will present you with a /dev/whatever you want interface to the netgraph subsystem. That might be a starting point, as your work is also a netgraph node. Yeah, i know. I think, i have the source. It is most likely outdated. In the version i have you create a new device entry per hook, but what i really wanted is one device per node with ability to clone devices. I.e. two (or more) things open /dev/foo and each of them get unique private context within node. Since it is not going to work anyway, i will stick to multiple hooks idea which would fit perfectly into ng_device interface. thanks, max __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
On Tue, 11 Jun 2002, Terry Lambert wrote: TLHarti Brandt wrote: TL TLFor a sound device, it would be nice if multiple instances to the TL TLdevices were mux'ed. I've had cases where the program I was using TL TLwas using a smaller number that the total available channels, and TL TLit would have been nice if the next open instance got the remaining TL TLchannels, rather than a device in use error. You'd have to manage TL TLthis by giving all remaining available channels to an opener, and TL TLthen having them ioctl() the unused ones back (e.g. allocate N TL TLwhen there are M available, means give M-N back). TL TL That has also nothing to do with cloning. Look at the current pcm driver - TL it just has a device entry per channel. TL TLA device entry per channel is a stupid idea. It means that I can TLnot write software to open the sound device, I have gto write TLsoftware to open the *right* sound device out of N sound devices, TLso that I get the right channel. It's a lot easier to just open TLthe thing, than it is to teach every single piece of software that TLuses sound to do the right thing, and know how to do that. If TLnothing else, it wil mean an incredible duplication of code in all TLsound using user space programs, and programs written by naieve TLprogrammers (yeah, I know -- like rattus giganticus, they don't TLexist, right) so that if you want to run A and B, you have to run TLB first, because B doesn't know aboout anything but the first sound TLdevice. This is just a recipe for disaster. You just don't know what you are talking about. This is exactly the difference between the current Linux sound (1 device) and FreeBSD (1 device/channel). In FreeBSD I can use N channels with different audio formats and speeds, in Linux I'm stuck to using all the channels with the same format. Try to write a conferencing tool, that has to work in a heterogenous environment. TL Where cloning could come into the TL play is when more than one process tries to open a 1-channel device and TL you want to mix the audio. As I said this would be a task of a layer above TL the sound driver (just as X 'multiplexes' N processes onto one display TL device). Unfortunately there is no good sound API up to now. TL TLIf only you could differentiate open instances of the same device TLfrom each other, so that mixing would just be implied, and just TLwork... if only the sound device were a *cloning device*. 8-). Yes. And to open a file on disk I open /dev/da0s1a and then issue an ioctl to get to the file (and a new device entry) and every disk driver implements the file system. Every sound device writer writes all the mixing and code conversion code into his driver... Just idiotic... Mixing and code conversion is something you should do above the device layer, just as you do TCP not in the network driver. What's the the API that the user program sees from this generic layer is just a matter of taste - cloning pseudo devices would be just fine. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
Harti Brandt wrote: You just don't know what you are talking about. This is exactly the difference between the current Linux sound (1 device) and FreeBSD (1 device/channel). In FreeBSD I can use N channels with different audio formats and speeds, in Linux I'm stuck to using all the channels with the same format. Try to write a conferencing tool, that has to work in a heterogenous environment. That's not an artifact of it being a single device; with a context per open instance, it's either an artifact of inability to manipulate the instance data via ioctl(), or the failure of the user software to open the underlying device more than once, so that it has different instances to work with to achieve your goal. From an application point of view, the only difference is whether you have to guess names to get at the extra channels, or just open the same name more than once. In FreeBSD, the device names are only a proxy for the differences in major/minor number pairs (as are all devices). The differences in minor numbers are themselves just a proxy for instance information. Where the instance comes from is really irrelevent, to the application, so long as it gets (1) one instance per fd, and (2) more than one fd. The only *real* difference I can see here is that programs built to run against the Linux ABI won't behave correctly when run on FreeBSD under FreeBSD's Linux ABI implementation. Yes. And to open a file on disk I open /dev/da0s1a and then issue an ioctl to get to the file (and a new device entry) and every disk driver implements the file system. Every sound device writer writes all the mixing and code conversion code into his driver... Just idiotic... This is a reductio ad absurdum argument. It leaves no room for the idea that there exist inappropriate applications of technology. Just because a hammer works once, does not make every problem a nail. If you looked at the recent followup by the original poster, you will see that what he has, in fact, is a device driver that really needs to permit him formatted access to a bus. A bus is an application for which cloning is a *really* good model to use for devices. Mixing and code conversion is something you should do above the device layer, just as you do TCP not in the network driver. What's the the API that the user program sees from this generic layer is just a matter of taste - cloning pseudo devices would be just fine. I understand your point, but I think you have chosen a particularly bad example. The problem with this example is that there have been a very large number of times where I have thought it would be useful to be able to have the TCP connection associated with the active browser window (the one in the foreground and/or the one that is selected as the active window -- having the input focus) have a higher priority than the other TCP connections associated with other windows belonging to the same browser application. It would be incredibly useful if I could start a number of downloads that I know will take a long time, and then continue browsing, and have the application just do what I want, by prioritizing traffic based on which window has my personal attention. I know that the typical answer to this is rewrite the Internet to support QOS, but this isn't really an answer. Without a negotiated QOS, I can still control the number of buffers in use on the peer which provides my connectivity by diddling with the window size advertisements my machine sends to the peer router, so that the peer router buffers don't become saturated with data for the file transfer sessions, and therefore my interactive response does not suffer (the current AltQ integration into FreeBSD does *NOT* use this technique, and so can not make the same guarantees, particularly when there is an inpedence mismatch between the ISP link and the last mile link to my machine, with my last mile being significantly slower). Julian Elisher built something similar to this into the Whistle InterJet, near the end, but it was only useful for trafic shaping, not explicit QOS control by the application. I guess my point to this whole example is that where you draw the line dictates the properties of the resulting system, and the more control you give to the application, the better, in most cases. In a perfect world, I think this would include TCP. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
About 1 year ago, I ported a proprietary linux driver to FreeBSD 4.x. I needed to support linux binaries which use device cloning. I came up with the following hack. The Linux driver code I ported from is under NDA, but I feel safe in posting this with the names obscured. The just of it is that on open, I create a new vnode and struct file which holds a pointer to a unique (per-instance) data structure. This allows me to track the private data associated with each open. Its ugly, but it works for what this driver needs to do. Perhaps something like this might work for you. Cheers, Drew /* * Open method, corresponds to most of XXXNicOpen. Allocates an owner * id and a private data structure. * * Each time FOO is opened, a new file and vnode is allocated to it. */ static int foo_open(dev_t kdev, int oflags, int devtype, struct proc *p) { int priv_id = -1; foo_private *priv = NULL; int num, error; int fd; struct file *fp; struct vnode *vn = NULL, *vd = NULL; if (p-p_dupfd = 0) return ENODEV; num = 0;/* xxx one NIC only */ error = foo_open_connection(num, (void **)priv, priv_id, oflags, NULL); if (error) return error; priv-p = p;/* process */ if ((error = falloc(p, fp, fd)) != 0) return error; /* XXX leaks priv */ vd = SLIST_FIRST(kdev-si_hlist); /* * Conjure up our own vnode out of thin air. We need the * vnode so that we can stash a pointer to the per-connection * priv struct for use in open/close/ioctl and mmap. This is * tricky, because we need make it look enough like the device * vnode so that VOP_GETATTR() works on the slave vnode in mmap() */ if ((error = getnewvnode(VT_NON, (struct mount *)0, vd-v_op, vn))) return error; /* XXX leaks fp priv */ vn-v_type = VCHR; /* really should clone v_vdata not copy pointer */ vn-v_data = vd-v_data;/* for VTOI in ufs_getattr() */ insmntque(vn, vd-v_mount); /* for VFSTOUFS in ufs_getattr() */ /* allocate our own rdev save the uniq priv */ vn-v_rdev = malloc(sizeof(struct specinfo), M_DEVBUF, M_WAITOK); bcopy(vd-v_rdev, vn-v_rdev, sizeof(struct specinfo)); vn-v_rdev-si_drv2 = (void *)priv; fp-f_data = (caddr_t)vn; fp-f_flag = FREAD|FWRITE; fp-f_ops = foo_fileops; fp-f_type = DTYPE_VNODE; /* so that we can mmap */ /* * Save the dup fd in the proc structure then return the * special error code (ENXIO) which causes magic things to * happen in vn_open. The whole concept is, well, hmmm. */ p-p_dupfd = fd; return ENXIO; } /* * File operations on FOO device instances * * Each FOO instance has a separate file, vnode, devnode, and specinfo * structures associated with it (see foo_open). * Private device data are stored with the specinfo (si_drv2) */ #include sys/file.h #include sys/stat.h int foo_fileread __P((struct file *fp, struct uio *uio, struct ucred *cred, int flags, struct proc *p)); int foo_filewrite __P((struct file *fp, struct uio *uio, struct ucred *cred, int flags, struct proc *p)); int foo_fileclose __P((struct file *fp, struct proc *p)); int foo_fileioctl __P((struct file *fp, u_long cmd, caddr_t data, struct proc *p)); int foo_filepoll __P((struct file *fp, int events, struct ucred *cred, struct proc *p)); int foo_filestat __P((struct file *fp, struct stat *ub, struct proc *p)); int foo_fileread(fp, uio, cred, flags, p) struct file *fp; struct uio *uio; struct ucred *cred; struct proc *p; int flags; { return 0; } int foo_filewrite(fp, uio, cred, flags, p) struct file *fp; struct uio *uio; struct ucred *cred; struct proc *p; int flags; { return 0; } int foo_fileioctl(fp, cmd, data, p) struct file *fp; u_long cmd; register caddr_t data; struct proc *p; { struct vnode *vn; struct specinfo *si; foo_private *priv; struct foo_softc *sc; int val = 0; vn = (struct vnode *)fp-f_data; si = vn-v_rdev; priv = si-si_drv2; sc = priv-sc; switch (cmd) { ... default: return -EINVAL; } return val; } int foo_filepoll(fp, events, cred, p) struct file *fp; int events; struct ucred *cred; struct proc *p; { return EOPNOTSUPP; } int foo_filestat(fp, ub, p) struct file *fp; struct stat *ub; struct proc *p; { return EOPNOTSUPP; } void insmntque __P((struct vnode *vp,
Re: Device cloning
On Tue, 2002-06-11 at 06:45, Poul-Henning Kamp wrote: The idea is simple: the same device(major,minor) can be opened several times by different processes (or possibly threads within the same process) and each process (thread) will have unique device instance. Sorry, but this wont work for a large number of reasons. For one thing none of the dup(2) or fork(2) like systemcalls report what happens to the filedescriptors down to the device drivers so you have no way to correctly track which process or which instance you are working on. Can't you kludge this by creating /dev/foo0 and when it is opened replacing it with a different minor number? Or perhaps /dev/foo0 as a symlink to /dev/foo0.0 and when it is opened create /dev/foo0.1 and change the symlink. This is obviously a different major,minor pair but those are the constraints in the system :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
On Mon, 10 Jun 2002, Maksim Yevmenkin wrote: MYHackers, MY MYThe project i'm working on might require some sort of MYdevice cloning. The current way of cloning, i.e. use MYDEVFS and allocate unique minor numbers, is not very MYgood for my purpose. MY MYThe idea is simple: the same device(major,minor) can MYbe opened several times by different processes (or MYpossibly threads within the same process) and each MYprocess (thread) will have unique device instance. MYDevice driver will create new instance, every time MYopen() called. It will use D_TRACKCLOSE flag and MYdestroy instances in close(). MY MYWhat kind of information should i store to identify MYeach instance? Is/Will it be possible to identify a MYsingle thread within a process? Is there any problems MYwith fork()? The support for the threads is optional. MYI can live with single instance per process. In MHO this idea is based on a fundamental misunderstanding of what a device is under unix. If you need such a behaviour you should put another abstraction on top of you devices (as the filesystem is put on top of disks and sockets on top of network devices), that handle multiple contexts for multiple processes. A device is just a device... harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
Harti Brandt wrote: In MHO this idea is based on a fundamental misunderstanding of what a device is under unix. If you need such a behaviour you should put another abstraction on top of you devices (as the filesystem is put on top of disks and sockets on top of network devices), that handle multiple contexts for multiple processes. A device is just a device... I really disagree with this. SVR4 and AIX have supported clone devices for a very long time now, starting with support for pty's. Cloning eliminates several things: o The search requirement for allocating an instance of a device type; this is generally a linear search, through an O(n^2) interface, e.g. looking up the next pty in the space defined by /dev/pty* o The normal limit on the number of devices that's imposed because of both the namespace limits, and on static declaration of things that should be allocated on a per instance bases, up to the limits of system resources o The system dependence on naming that goes into building code that it portable between systems. For pty's, in particular, instance is identified via minor number; the need to actually try to open and obtain exclusive use of the master pty, up to the first unallocated one, and the fact that when you run out of names, you run out of pty's, are both enough, each on their own, to justify cloning devices. FreeBSD today can not run more than one VMWare seassion at a time because it lacks the ability to distinguish open instances to the device that exports the VMWare kernel context information to the user space application: because FreeBSD lacks device cloning. Rather than trying to say what someone should do, it'd be nice, at least in the case of commercial code that can't be demanded to be rewritten, and which runs under a non-native ABI on FreeBSD, to be able to support all of the functionality of the OS whose ABI is being emulated, and thus, if for no other reason, to support device cloning. It's not like third parties are going to be willing to port their code to FreeBSD, particularly after the last 6 years or so of being told *by FreeBSD people* to target the Linux ABI. So trying to change people wanting cloning in the first place is not really a winable fight. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
On Tue, 11 Jun 2002, Terry Lambert wrote: TLHarti Brandt wrote: TL In MHO this idea is based on a fundamental misunderstanding of what a TL device is under unix. If you need such a behaviour you should put another TL abstraction on top of you devices (as the filesystem is put on top of TL disks and sockets on top of network devices), that handle multiple TL contexts for multiple processes. A device is just a device... TL TLI really disagree with this. SVR4 and AIX have supported clone TLdevices for a very long time now, starting with support for pty's. TL TLCloning eliminates several things: TL TLoThe search requirement for allocating an instance of a TL device type; this is generally a linear search, through TL an O(n^2) interface, e.g. looking up the next pty in the TL space defined by /dev/pty* TL TLoThe normal limit on the number of devices that's imposed TL because of both the namespace limits, and on static TL declaration of things that should be allocated on a per TL instance bases, up to the limits of system resources TL TLoThe system dependence on naming that goes into building TL code that it portable between systems. TL TLFor pty's, in particular, instance is identified via minor number; TLthe need to actually try to open and obtain exclusive use of the TLmaster pty, up to the first unallocated one, and the fact that TLwhen you run out of names, you run out of pty's, are both enough, TLeach on their own, to justify cloning devices. TL TLFreeBSD today can not run more than one VMWare seassion at a time TLbecause it lacks the ability to distinguish open instances to the TLdevice that exports the VMWare kernel context information to the TLuser space application: because FreeBSD lacks device cloning. TL TLRather than trying to say what someone should do, it'd be nice, TLat least in the case of commercial code that can't be demanded to TLbe rewritten, and which runs under a non-native ABI on FreeBSD, TLto be able to support all of the functionality of the OS whose TLABI is being emulated, and thus, if for no other reason, to TLsupport device cloning. TL TLIt's not like third parties are going to be willing to port their TLcode to FreeBSD, particularly after the last 6 years or so of TLbeing told *by FreeBSD people* to target the Linux ABI. TL TLSo trying to change people wanting cloning in the first place is TLnot really a winable fight. Terry, I was talking about real devices, not pseudo devices that you can get out of thin air. Device driver for real devices should be just what they are: device drivers. If you take a disk driver, then there is no code there that tries to present multiple contexts to multiple openers - supporting this is the task of the file system. If you take a sound card, the multiplexing stuff, that handles multiple processes open the soundcard should not be in the driver, but in the abstraction above. The same holds for the network devices. The situation is different for pseudo devices which you can create on demand. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
Harti Brandt wrote: I was talking about real devices, not pseudo devices that you can get out of thin air. Device driver for real devices should be just what they are: device drivers. If you take a disk driver, then there is no code there that tries to present multiple contexts to multiple openers - supporting this is the task of the file system. If you take a sound card, the multiplexing stuff, that handles multiple processes open the soundcard should not be in the driver, but in the abstraction above. The same holds for the network devices. The situation is different for pseudo devices which you can create on demand. This is true for most real devices, but not all of them. For a disk device, it would be nice if I could ioctl() it to change it's instance to that of a parent, e.g. for slice management. For a sound device, it would be nice if multiple instances to the devices were mux'ed. I've had cases where the program I was using was using a smaller number that the total available channels, and it would have been nice if the next open instance got the remaining channels, rather than a device in use error. You'd have to manage this by giving all remaining available channels to an opener, and then having them ioctl() the unused ones back (e.g. allocate N when there are M available, means give M-N back). For a DVD, it would be nice if you could select the instance of the device you were going to get for seperation of the ISO9660 and UDF FS's (e.g. which record boundary the device actually used). The way that OS X supports this is by doing DVD mounts on both the character and block device seperately. For FreeBSD, UDF support, which has to have access to the ISO9660 FS for the purposes of index access, is much more messy. You could also make an argument for multiple input devices and the management of which one you get when you open /dev/mouse. Finally, there's a long history on SCO Xenix and UNIX, starting with Computone multiport serial cards, of multiplexing access to the device seperately for printing vs. terminal I/O. Yes, Digiboard and other vendors handle this by having two device nodes for a single pgysical device, and maintaining a state machine for the escape sequences. But this is really a matter of preference, not necessity. Writing to one instance, you talk to the terminal, and writing to the other, you talk to the aux port. I don't think the original poster wanted cloning for support on physical devices for which there was a 1:1 relationship anyway (8^)), but there *are* cases where it could be useful. Actually, I think the original poster never really disclosed *what* they wanted to use the feature for... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
On Tue, 11 Jun 2002, Terry Lambert wrote: TLHarti Brandt wrote: TL I was talking about real devices, not pseudo devices that you can get out TL of thin air. Device driver for real devices should be just what they are: TL device drivers. If you take a disk driver, then there is no code there TL that tries to present multiple contexts to multiple openers - supporting TL this is the task of the file system. If you take a sound card, the TL multiplexing stuff, that handles multiple processes open the soundcard TL should not be in the driver, but in the abstraction above. The same holds TL for the network devices. The situation is different for pseudo devices TL which you can create on demand. TL TLThis is true for most real devices, but not all of them. TL TLFor a disk device, it would be nice if I could ioctl() it to change TLit's instance to that of a parent, e.g. for slice management. Can't see any 'cloning' here. TLFor a sound device, it would be nice if multiple instances to the TLdevices were mux'ed. I've had cases where the program I was using TLwas using a smaller number that the total available channels, and TLit would have been nice if the next open instance got the remaining TLchannels, rather than a device in use error. You'd have to manage TLthis by giving all remaining available channels to an opener, and TLthen having them ioctl() the unused ones back (e.g. allocate N TLwhen there are M available, means give M-N back). That has also nothing to do with cloning. Look at the current pcm driver - it just has a device entry per channel. Where cloning could come into the play is when more than one process tries to open a 1-channel device and you want to mix the audio. As I said this would be a task of a layer above the sound driver (just as X 'multiplexes' N processes onto one display device). Unfortunately there is no good sound API up to now. TLFor a DVD, it would be nice if you could select the instance of the TLdevice you were going to get for seperation of the ISO9660 and UDF TLFS's (e.g. which record boundary the device actually used). The way TLthat OS X supports this is by doing DVD mounts on both the character TLand block device seperately. For FreeBSD, UDF support, which has to TLhave access to the ISO9660 FS for the purposes of index access, is TLmuch more messy. No cloning here. TLYou could also make an argument for multiple input devices and the TLmanagement of which one you get when you open /dev/mouse. Again you just get it the wrong way around. You need per process/open context if you try to put the multiplexing of ONE mouse between MULTIPLE processes into the hardware mouse driver. Again this would be plain wrong. TLFinally, there's a long history on SCO Xenix and UNIX, starting with TLComputone multiport serial cards, of multiplexing access to the TLdevice seperately for printing vs. terminal I/O. Yes, Digiboard and TLother vendors handle this by having two device nodes for a single TLpgysical device, and maintaining a state machine for the escape TLsequences. But this is really a matter of preference, not necessity. TLWriting to one instance, you talk to the terminal, and writing to the TLother, you talk to the aux port. Again this is not about 'cloning a physical' device. TLI don't think the original poster wanted cloning for support on TLphysical devices for which there was a 1:1 relationship anyway TL(8^)), but there *are* cases where it could be useful. TL TLActually, I think the original poster never really disclosed *what* TLthey wanted to use the feature for... That's true... From reading the original post I was under the impression that this is again a 'hey, I write a device driver and I need to track the number of opens and to tack a context onto each open' that periodically comes up. If I'm wrong, well, sorry then... harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
Hackers, [...] TLI don't think the original poster wanted cloning for support on TLphysical devices for which there was a 1:1 relationship anyway TL(8^)), but there *are* cases where it could be useful. TL TLActually, I think the original poster never really disclosed *what* TLthey wanted to use the feature for... That's true... From reading the original post I was under the impression that this is again a 'hey, I write a device driver and I need to track the number of opens and to tack a context onto each open' that periodically comes up. If I'm wrong, well, sorry then... I'm sorry people :) I should have been more specific. Here is what i meant. I'm working on Bluetooth stack for FreeBSD. Everything is implemented in Netgraph. The real device driver nodes are connected to HCI layer. You can talk to any Bluetooth device via HCI layer. It does not really matter what kind of device you have, PC-CARD, serial or USB dongle. They all MUST talk via HCI. So HCI is not really a device driver, and, IMO, it is not a pseudo device driver. It sort of looks like /dev/tcp :) Currently there is a single control hook for every HCI node. Control application connects to the hook and sends HCI commands and receives HCI events. It does work, but once the hook is connected, nobody else can connect to the same hook. That is a limitation, IMO. It would really be nice to have several control applications. For example, - HCI dump (a-la tcpdump) - HCI link key/PIN manager (security) My choices were: 1) Create /dev/hci[0-9]+ for every HCI node and implement cloning pid 1 - /dev/hci0 -+- hci0 node - device driver node pid 2 - /dev/hci0(clone 0) -+ This will not work work. 2) Raw HCI sockets The problem here is how to identify device, i.e. what to put into sockaddr? Netgraph node name? May be not a good choice, because it can be changed at any time. Device BD_ADDR? Does not work also, because in order to get BD_ADDR you must send HCI command to the device. 3) Multiple control/raw Netgraph hooks I like it best for now. Each hook will have a filter and every message/data will be delivered to each hook if it has not been filtered. Anyway, i got answers i wanted. Thanks everyone. thanks, max __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
In message [EMAIL PROTECTED], Maksim Yevmenk in writes: I'm sorry people :) I should have been more specific. Here is what i meant. I'm working on Bluetooth stack for FreeBSD. Everything is implemented in Netgraph. The real device driver nodes are connected to HCI layer. You can talk to any Bluetooth device via HCI layer. It does not really matter what kind of device you have, PC-CARD, serial or USB dongle. They all MUST talk via HCI. So HCI is not really a device driver, and, IMO, it is not a pseudo device driver. It sort of looks like /dev/tcp :) That's called a protocol family in BSD and you access it using sockets. Based on what little I know about Blåtand it will be much easier to work with as a socket than as a /dev/bla entry. Currently there is a single control hook for every HCI node. Control application connects to the hook and sends HCI commands and receives HCI events. It does work, but once the hook is connected, nobody else can connect to the same hook. That is a limitation, IMO. It would really be nice to have several control applications. For example, This is exactly the kind of semantics sockets offer you. 2) Raw HCI sockets The problem here is how to identify device, i.e. what to put into sockaddr? Netgraph node name? May be not a good choice, because it can be changed at any time. Device BD_ADDR? Does not work also, because in order to get BD_ADDR you must send HCI command to the device. Well, many TCP clients don't care about the name, so they ask for INADDR_ANY and get whatever the kernel feels like giving them, you could do the same and have the kernel hand out random numbers. In fact, you don't actually have to call bind(2) at all, you can just call socket(2) and run with the result... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
I'm sorry people :) I should have been more specific. Here is what i meant. I'm working on Bluetooth stack for FreeBSD. Everything is implemented in Netgraph. The real device driver nodes are connected to HCI layer. You can talk to any Bluetooth device via HCI layer. It does not really matter what kind of device you have, PC-CARD, serial or USB dongle. They all MUST talk via HCI. So HCI is not really a device driver, and, IMO, it is not a pseudo device driver. It sort of looks like /dev/tcp :) That's called a protocol family in BSD and you access it using sockets. Well, HCI _IS_NOT_ a network protocol like TCP or even UDP. It is a predefined set of control messages and events that user might send to the device. L2CAP which is runs over HCI _IS_ a network protocol and it is implemented in AF_BLUETOOTH protocol family. So application can say s = socket(AF_BLUETOOTH, SOCK_SEQ, BTPROTO_L2CAP) and then bind(s) and connect(s). Based on what little I know about Blåtand it will be much easier to work with as a socket than as a /dev/bla entry. Currently there is a single control hook for every HCI node. Control application connects to the hook and sends HCI commands and receives HCI events. It does work, but once the hook is connected, nobody else can connect to the same hook. That is a limitation, IMO. It would really be nice to have several control applications. For example, This is exactly the kind of semantics sockets offer you. 2) Raw HCI sockets The problem here is how to identify device, i.e. what to put into sockaddr? Netgraph node name? May be not a good choice, because it can be changed at any time. Device BD_ADDR? Does not work also, because in order to get BD_ADDR you must send HCI command to the device. Well, many TCP clients don't care about the name, so they ask for INADDR_ANY and get whatever the kernel feels like giving them, you could do the same and have the kernel hand out random numbers. Again, i have to ask specific device on _HCI_ layer. Here is an example. User plugged the card. Now HCI layer MUST query the card and ask - what is the BD_ADDR (MAC) ? - what are the capabilities of the device? - what is the size of the data buffer? - etc. HCI layer _has_ all this commands defined. In fact control application sends several HCI commands to the device to initialze it. After device is connected to the stack - no problem - you now can use BD_ADDR in sockaddr and do whatever you want to do. thanks, max __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
Harti Brandt wrote: TLFor a sound device, it would be nice if multiple instances to the TLdevices were mux'ed. I've had cases where the program I was using TLwas using a smaller number that the total available channels, and TLit would have been nice if the next open instance got the remaining TLchannels, rather than a device in use error. You'd have to manage TLthis by giving all remaining available channels to an opener, and TLthen having them ioctl() the unused ones back (e.g. allocate N TLwhen there are M available, means give M-N back). That has also nothing to do with cloning. Look at the current pcm driver - it just has a device entry per channel. A device entry per channel is a stupid idea. It means that I can not write software to open the sound device, I have gto write software to open the *right* sound device out of N sound devices, so that I get the right channel. It's a lot easier to just open the thing, than it is to teach every single piece of software that uses sound to do the right thing, and know how to do that. If nothing else, it wil mean an incredible duplication of code in all sound using user space programs, and programs written by naieve programmers (yeah, I know -- like rattus giganticus, they don't exist, right) so that if you want to run A and B, you have to run B first, because B doesn't know aboout anything but the first sound device. This is just a recipe for disaster. Where cloning could come into the play is when more than one process tries to open a 1-channel device and you want to mix the audio. As I said this would be a task of a layer above the sound driver (just as X 'multiplexes' N processes onto one display device). Unfortunately there is no good sound API up to now. If only you could differentiate open instances of the same device from each other, so that mixing would just be implied, and just work... if only the sound device were a *cloning device*. 8-). TLFor a DVD, it would be nice if you could select the instance of the TLdevice you were going to get for seperation of the ISO9660 and UDF TLFS's (e.g. which record boundary the device actually used). The way TLthat OS X supports this is by doing DVD mounts on both the character TLand block device seperately. For FreeBSD, UDF support, which has to TLhave access to the ISO9660 FS for the purposes of index access, is TLmuch more messy. No cloning here. ??? You are suggesting two devices? That's quite interesting. I suppose it's possible, if you absolutely insist on it. I guess pushing the complexity from a relatively trivial device driver operation into a much more complex file system operation would work. IMO, though, it would not really be a good idea. It's like laying carpet, and leaving a bubble in it. You can chase it all around your living room, but the bubble is going to be *somewhere*. TLYou could also make an argument for multiple input devices and the TLmanagement of which one you get when you open /dev/mouse. Again you just get it the wrong way around. You need per process/open context if you try to put the multiplexing of ONE mouse between MULTIPLE processes into the hardware mouse driver. Again this would be plain wrong. I'm not *talking* about multiple processes. For example, I have three mice on the machine from which I am currently typing: 1) A 3 button USB two axis optical mouse 2) A 2 buttom glidepoint two axis touchpad 3) A 1 button one axis jogdial All of these are devices to mux into a single program, the X server, and from there, into the Window Manager, so that I can make them behave as they do under Windows (e.g. my jogdial input needs to be routed to a popup utility that can launch programs). While my #1 and #2 need to be treated as synonyms (including treating the third button on the optical mouse the same as a chord of button 12 on the touchpad). I'd rather not have to go outside the normal operation of my X server input manager, in order to be able to achieve this. I'd rather just set it up so that the jogdial were reported as button events. TLFinally, there's a long history on SCO Xenix and UNIX, starting with TLComputone multiport serial cards, of multiplexing access to the TLdevice seperately for printing vs. terminal I/O. Yes, Digiboard and TLother vendors handle this by having two device nodes for a single TLpgysical device, and maintaining a state machine for the escape TLsequences. But this is really a matter of preference, not necessity. TLWriting to one instance, you talk to the terminal, and writing to the TLother, you talk to the aux port. Again this is not about 'cloning a physical' device. You're high. What happens when I have two programs, and one of them doesn't know to make it's write of escape sequences atomic, because it's not expecting a second program to be sending escape sequences to select and deselect output to the AUX port on the terminal?!? Someone, somewhere has to
Re: Device cloning
Maksim Yevmenkin wrote: I'm sorry people :) I should have been more specific. Here is what i meant. I'm working on Bluetooth stack for FreeBSD. Everything is implemented in Netgraph. The real device driver nodes are connected to HCI layer. You can talk to any Bluetooth device via HCI layer. It does not really matter what kind of device you have, PC-CARD, serial or USB dongle. They all MUST talk via HCI. So HCI is not really a device driver, and, IMO, it is not a pseudo device driver. It sort of looks like /dev/tcp :) Ah. You have a device which is an addressable bus. Yes, if cloning worked, it would be the best way to implement it. The typical BSD way of dealing with this would probably be to create a socket interface. The problem with a socket interface is that you woun't be able to run standard protocols over top of your HCI, unless you (re)implement them as netgraph nodes (e.g. like a /dev/tcp with a streams stack pushed on it). I think that your current Netgraph approach is probably the best one available to you, if you want to avoid additional plumbing work. Good luck on your work, it sounds interesting! -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
Maksim Yevmenkin wrote: Well, HCI _IS_NOT_ a network protocol like TCP or even UDP. It is a predefined set of control messages and events that user might send to the device. L2CAP which is runs over HCI _IS_ a network protocol and it is implemented in AF_BLUETOOTH protocol family. So application can say s = socket(AF_BLUETOOTH, SOCK_SEQ, BTPROTO_L2CAP) and then bind(s) and connect(s). You might want to look at how you issue raw SCSI commands on devices via CAM. You can start with man cam. Your situation is exactly analogous (IMO) to a device interface to a raw bus. You will notice that most of it is section 3 (e.g. implemented in a set of user space library routines on top of the SCSI bus commands). If you look at how the CAM toys talk to the SCSI bus itself, though, you will see an interface for jamming known format SCSI commands down onto a SCSI bus, which is probably the level at which you want your interface. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
In message [EMAIL PROTECTED], Maksim Yevmenk in writes: Hackers, The project i'm working on might require some sort of device cloning. The current way of cloning, i.e. use DEVFS and allocate unique minor numbers, is not very good for my purpose. The idea is simple: the same device(major,minor) can be opened several times by different processes (or possibly threads within the same process) and each process (thread) will have unique device instance. Sorry, but this wont work for a large number of reasons. For one thing none of the dup(2) or fork(2) like systemcalls report what happens to the filedescriptors down to the device drivers so you have no way to correctly track which process or which instance you are working on. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
÷ Tue, 11.06.2002, × 01:15, Poul-Henning Kamp ÎÁÐÉÓÁÌ: In message [EMAIL PROTECTED], Maksim Yevmenk in writes: Hackers, The project i'm working on might require some sort of device cloning. The current way of cloning, i.e. use DEVFS and allocate unique minor numbers, is not very good for my purpose. The idea is simple: the same device(major,minor) can be opened several times by different processes (or possibly threads within the same process) and each process (thread) will have unique device instance. Sorry, but this wont work for a large number of reasons. For one thing none of the dup(2) or fork(2) like systemcalls report what happens to the filedescriptors down to the device drivers so you have no way to correctly track which process or which instance you are working on. As far as I understand _key_ word is open, each new instance appears on open(), but fork() and dup() only do regular work. dup'ed or fork'ed descriptors will be same from driver's point of view, but each new open() will create new instance. Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -- Vladimir B. Grebenschikov [EMAIL PROTECTED], SWsoft, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
Vladimir B. Grebenschikov wrote: As far as I understand _key_ word is open, each new instance appears on open(), but fork() and dup() only do regular work. dup'ed or fork'ed descriptors will be same from driver's point of view, but each new open() will create new instance. No. The problem is that if you open the same thing N times, you will get N references to the single vnode of the thing. For devices, it's possible to kludge this, so that the device gives you a different vnode for each instance; however, the close is not sufficiently tracked unless you also give back a different minor number for each open instance. The problem is that there is no per reference instance information that is stored with the vnode and given to the device, as a context, with each operation, other tha the device context itself. So the only way to do this is a different minor number, so that the device is capable of maintaining its own per open instance information. It's also really questionable what the correct course of action for the fork/dup/dup2 code is. Consider the case of a program that intentionally forks, so that one process can read from the /etc/tty and write to the device, while the other can do the opposite (this is how the original cu program worked). On top of this, add descriptor passing. This breaks down to: are you creating a new open instance, or are you manipulating a reference to an existing open instance? Pushing this information over the struct fileops barrier is not a very easy thing to do. It would require reorganization of a lot of code. While this code is in *dire* need of reorganization, when you are done, if you can't answer the question about whether you are doing a dup or passing a reference to a single instance when you pass an FD between processes... well... you're in a bit of a jam. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message