Re: User asks: can we decouple device vendor IDs from drivers?
M. Warner Losh writes: The problem with decoupling things entirely from the drivers is that many drivers will say if I have this revision of that card, do this workaround. or if I'm this or newer, I have this feature both of which are broken by the kernel forcing the driver to service a given hunk of hardware. Hmm. Careful design may sort this out, methinks. If the file (which sounds analagous to /boot/device.hints to me) turned devid's into generic griver requrements (DEVID(0x04589045) == driver(foo) revision(bar) flags(baz, qux)) would that not be usable? (/me wonders if he has the time to do this - he's certainly interested) The other down side is that when you bork the alias file on solaris, you are so hozed. ... like most of the files in /boot/... However, it would make the dynamic loading of drivers easier. I really like to concept of configuring things with vi(1), instead of with gcc :-) M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: proposed new builtin for /bin/sh (associative arrays)
* Oliver Fromme [EMAIL PROTECTED] [2003-10-31 21:16 +0100]:
Maybe I'm not understanding your intentions, but isn't that
already possible using set | sed -n '/^foo_/s/=.*//p'?
Or do you want to avoid external programs? In that case it
would be a little bit more difficult to do, but it's still
possible to do with existing builtins:
indexes()
{
for i in `set`; do
case $i in
$1*) echo ${i%%=*}
esac
done
}
I think both of these could fail with multiline values.
Nicolas
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: User asks: can we decouple device vendor IDs from drivers?
In message: [EMAIL PROTECTED] Mark Murray [EMAIL PROTECTED] writes: : M. Warner Losh writes: : The problem with decoupling things entirely from the drivers is that : many drivers will say if I have this revision of that card, do this : workaround. or if I'm this or newer, I have this feature both of : which are broken by the kernel forcing the driver to service a given : hunk of hardware. : : Hmm. Careful design may sort this out, methinks. If the file (which : sounds analagous to /boot/device.hints to me) turned devid's into : generic griver requrements (DEVID(0x04589045) == driver(foo) revision(bar) : flags(baz, qux)) would that not be usable? (/me wonders if he has the time : to do this - he's certainly interested) I think you miss the point of my objection. It isn't to match the card. That's trivially easy to do in a config file like the hints file (boot loader). The problem is that drivers often have code that looks like: if (id == CARD_3C589) set some flags else if (id == CARD_3C572) set some flags else some defaults. Now then, if 3com comes out with a new card that's like the 3c572 (say the 3c574), then the driver still has to be changed to grok the new card. However, if you say 'map this id to that id' then you could say 'map 3c574 to 3c572' and the driver would just work. See the difference? In your case, the default flags would be set, and the device would fail to work. In my case the driver thinks it is talking to a 3c572, and sets the flags correctly for that card. Maybe you need both, but the mapping feature is critical. Also, you need to do the same sorts of matching functionality that devd has to match things. If this replaces the 'probe' part of the system, then you also have to deal with those busses that aren't self-identifying. : The other down side is that when you bork the alias : file on solaris, you are so hozed. : : ... like most of the files in /boot/... No. You can boot if /boot is f*'d up fairly easily. If all the driver information is codified in one file, then you are one file away from having a totally hozed system. With the rest of the files in /boot/ there typically is a backup file that you can boot, ditto with kernel vs kernel.old. I've been ass raped by missing /etc/driver_aliases file on solaris many many times. I'm not keen on making it easier for freebsd to do this to its users. : However, it would make the dynamic loading of drivers easier. : : I really like to concept of configuring things with vi(1), instead of : with gcc :-) You can like that concept all you want. It is not completely appropriate to the driver stuff. There's typically only one or two drivers in the tree that have a large traffic in adding devices: ed and wi. Most of the other drivers in the tree do need occasional devices added, but There's actually a lot of work here to make this work right, and I'm not trying to get in the way of it. I just don't want to wind up with a half-assed system in the end. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: O_NOACCESS?
andi payn wrote: Now hold on. The standard (by which I you mean POSIX? or one of the UNIX standards?) doesn't say that you can't have an additional flag called O_NOACCESS with whatever value and meaning you want. A strictly conforming implementation can not expose things into the namespace that are not defined by the standard to be in the namespace, when a manifest constant specifying a conformance level is in scope. This is the main reason for things like _types.h. Obviously, code that relies on such a flag will be non-portable, since no standard defines such a flag, but that's fine, since the intended uses (writing a FreeBSD-specific backend for fam, for example) aren't expected to be portable anyway. Not justnot portable, but fails to conform to standards. If O_NOACCESS happens to be == O_ACCMODE on FreeBSD--just as it is on linux--and if that happens to also be == O_WRONLY | O_RDWR (with no other flags set), I don't see how that changes anything. Other than the security issues it raises, you mean, right? [ ... ] In which case, your example is (O_RDWR|O_WRONLY) == O_RDWR. The standard does not indicate whether the implementation is to use bits, or sequential manifest constants, only that the bits that make up the constants be in the range covered by O_ACCMODE. First, again, this is intended to be used for non-portable code, and therefore, the fact that this happens not to be true on FreeBSD means it's irrelevant that it could be true elsewhere. Especially since, if O_NOACCESS were added to FreeBSD, it would still fail to exist entirely on other platforms, which means it matters little what value it might have if it did exist--code written to use O_NOACCESS won't compile on platforms without O_NOACCESS. You nead to look at the implementation of VOP_OPEN in FreeBSD; specifically, you need to look at the fact that fp-f_flags is passed as one of its parameters, and that the FS is permitted to interpret these flags in an FS-dependent fashion. Then you need to at the fact that FreeBSD supports locadable FS types, and that there are third party FS's that proxy operations over the network, which can include a network version of the flags, and conversion back and forth could therefore end up being ambiguous. Really, it needs to be a bitmap internally in FreeBSD, as well, but that's a big step. Second, any platform that defines O_NOACCESS could do so differently. On FreeBSD, as on linux, the most sensible definition is O_NOACCESS == O_WRONLY | O_RDWR == 3. Or a platform that defined O_RDONLY as 1 and O_WRONLY as 2, the most sensible definition would be O_NOACCESS == 0. I pray this flag never gets adopted outside of Linux... In fact, externally, they are bits, but internally, in the kernel, they are manifest constants. Yes, FFLAGS and OFLAGS convert between the two. If you look at how this works in the linux kernel, you'll see that O_RDONLY (0) converts to FREAD (1); O_WRONLY (1) to FWRITE (2); O_RDWR (2) to FREAD | FWRITE (3); and O_NOACCESS (3) to 0. This could be done the same way in FreeBSD.* * Actually, this is a tiny lie; linux has a 2-bit internal access flags value which it derives in this way, and uses the original passed-in flags for everything except access. FreeBSD instead just adds 1, relying on the fact that the lower 2 bits will never be 3, and therefore all of the other bits will stay the same. This means that enabling this value would make the FFLAGS and OFLAGS macros slightly more complicated on FreeBSD. It would be more useful to intern them as a bitmap, IMO, and get rid of the conversion. The problm is compatability with historical source code passing literal constants instead of manifest values. The most useful thing you could do with this, IMO, is opn a directory for fchdir(). Except that you can already do exactly this with chdir(). But I can see that you might at some point want to check the directory before chdir'ing to it, or pass an fd down into some function instead of a string, and this would be useful in such a case. Or deal with issues of privilege granted merely by open. For example, on FreeBSD, an implementation of this would permit any normal user to do INB/OUTB to any I/O port on any hardare on the machine. This is a can of worms. Of course, allowing this on directories for which you are normally denied read/write permissions would be a neat way to escape from chroot'ed environments and compromise a host system... How would it allow that? If you can open files outside your chroot environment--even files you would otherwise have read access to--it's not much of a chroot! Mounted procfs within a chrooted environment. Admittedly, FreeBSD is moving away from procfs, but on Linux, it's a serious issue, since such basic utilities as ps and so on won't work without it. Having O_NOACCESS would be useful for the fam port, for porting pieces of lilo, and probably for other things I
Re: O_NOACCESS?
M. Warner Losh wrote: Rewind units on tape drives? If there's no access check done, and I open the rewind unit as joe-smoe? The close code is what does the rewind, and you don't have enough knowledge to know if the tape was opened r/w there. Which brings up the idea of passing fp-fd_flags to VOP_CLOSE()... -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
question about user space addressed, mmap, and getting phys address
Hi everyone, Sorry I am not on the list, but I was hoping someone here might be able to help me. I have a design that I cannot change that does the following: 1) Calls mmap on a chunk of memory that the device driver uses to DMA to a video decoder. 2) This chunk of memory is treated as several DMA buffers. There is an ioctl setup to indicate when a section of that memory is being used and when it is freed (usage count). I need to take the address from the mmap, add an offset, send it through an ioctl, and then relate it back to the physical address that it was originally mapped from. Unfortunately, the address I get from the ioctl is a user-space address and when I use vtophys I get back 0. Is there some other mechanism to convert a user-space address to a physical address? Any and all help will be greatly appreciated. Thanks in advance, Sean ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
dhclient dynamic DNS updates
I'm having problems getting dhclient to do dynamic DNS updates. I'm wondering if anyone else has gotten this working. I want dhclient to dynamically update a forward zone. I can't have the server do it, as I don't control the server (cable modem setup). I know I have named set up right, as I can have dhcpd update (at a different site) update the server just fine. So, my basic dynamic DNS config seems to be ok. I put the same key config and zone config in /etc/dhclient.conf. Right off the bat I noticed something odd, in dhcpd.conf 'secret' (in key) takes an argument in double quotes, qutoes in dhclient.conf give an error. With no quotes there's no error. Similarly for 'key' (in zone). Beyond that the only other things I've added are: prepend domain-name-servers 127.0.0.1; supersede domain-name my.example.com; send fqdn.fqdn hostname.my.example.com.; send fqdn.encoded on; send fqdn.server-update off; Best I can tell from the config this should make dhclient send a dynamic DNS update to the server listed as primary in the zone section adding hostname.my.example.com. However, tcpdump shows no DNS update packets of any kind coming from the machine running dhclient. What's the magic to get dhclient to emit a dynamic DNS update? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: O_NOACCESS?
On Sat, 2003-11-01 at 13:39, Terry Lambert wrote: andi payn wrote: Now hold on. The standard (by which I you mean POSIX? or one of the UNIX [...] A strictly conforming implementation can not expose things into the namespace that are not defined by the standard to be in the namespace, when a manifest constant specifying a conformance level is in scope. Yes. As I mentioned at the beginning, you don't get O_NOACCESS in linux by pulling in the standard headers, and I wasn't suggesting anything different. [...] Not justnot portable, but fails to conform to standards. Note that the Single UNIX Specification says that open _may_ fail with EINVAL if the value of the oflag argument does not contain exactly one of the three access modes. So, if you've written code (for some reason) that expects that it _must_ fail in such a situation, that's non-comforming code. If O_NOACCESS happens to be == O_ACCMODE on FreeBSD--just as it is on linux--and if that happens to also be == O_WRONLY | O_RDWR (with no other flags set), I don't see how that changes anything. Other than the security issues it raises, you mean, right? Are you saying that having O_NOACCESS == O_ACCMODE raises security issues beyond any raised by having O_NOACCESS at all? Or is it the fact that it would the same value as in linux, so linux code (whether recompiled for FreeBSD or run under ABI compatibility) that expected to be able to open a file without getting read or write access would be able to do so? Again, I don't see how this raises security issues beyond whatever may be inherent in O_NOACCESS, if any. Or are you just getting ahead of yourself? You nead to look at the implementation of VOP_OPEN in FreeBSD; specifically, you need to look at the fact that fp-f_flags is passed as one of its parameters, and that the FS is permitted to interpret these flags in an FS-dependent fashion. Which version are you looking at? In 5.1, what gets passed if fmode, which is ultimately the result of applying FFLAGS to the original flags passed to open. As for the FS being permitted to interpret these flags in an FS-dependent fashion: I'm pretty sure that a FS that interpreted FREAD to mean write permission, or O_APPEND to mean truncate, would not be considered good. Any FS that assumes that it can read if FREAD is set, and it can write if FWRITE is set, will work correctly when neither is set. And any filesystem that doesn't work this way is already broken. However, there may be some FS's with more subtle issues. For example, an FS might assume that if it doesn't have FWRITE, it must have FREAD. This is (probably) not guaranteed anywhere--but it is currently true, a fact which is logically deducible from the values of the flags, the way FFLAGS works, and the fact that O_ACCMODE returns EINVAL. If this ceases to be true, such an FS might do things wrong. I'd have no problem with providing for each filesystem to specify I can handle no-access opens, and for any FS that doesn't do so, the kernel would return EINVAL before even talking to the FS (thus preserving current behavior); only if the FS does so could it ever get an fmode with neither FREAD nor FWRITE set. [...] Really, it needs to be a bitmap internally in FreeBSD, as well, but that's a big step. By it needs to be a bitmap internally, you mean that fmode needs to be a bitmap? Well, then, good news: It already is. In fact, I think the equivalent parameter has been a bitmap for every *BSD and going back into ATT Unix. Currently FFLAGS() is a macro that adds 1. Now, look at the original flags. The low two bits are the O_ACCMODE mask. This part is not a bitmap (O_RDONLY == 0, O_WRONLY == 1, and O_RDWR == 2). But once you add 1, the result is (FREAD == 1, FWRITE == 2, FREAD|FWRITE == 3 == 1|2). The flags value with O_ACCMODE masked out is already a bitmap (not just in FreeBSD; it's even defined to be one in the Single Unix Standard). Adding 1 to flags could only change any of these bits if the two low bits were both 1. But this is not possible, since we've already checked that (flags O_ACCMODE) != O_ACCMODE. Therefore, fmode is a bitmap. QED. Now, what I'm proposing would allow the low two bits to be 11, which FFLAGS would map to 00 (as it does in linux). While adding 1 does this, it would also affect the higher bits (O_NOACCESS | O_NOBLOCK + 1 is not 0 | O_NOBLOCK, it's 0 | O_APPEND). Therefore, a slightly more complicated FFLAGS is needed if we want fmode to remain a bitmap. (The alternative--the way linux does this--is to pass along both flags and fflags, and using fflags only for the low two bits, which is ugly and messy. I'd much prefer a slightly more complicated FFLAGS.) Second, any platform that defines O_NOACCESS could do so differently. On FreeBSD, as on linux, the most sensible definition is O_NOACCESS == O_WRONLY | O_RDWR == 3. Or a platform that defined O_RDONLY as 1 and O_WRONLY as 2, the most sensible definition would be O_NOACCESS == 0. I pray this
Re: O_NOACCESS?
On Sat, 2003-11-01 at 13:44, Terry Lambert wrote: M. Warner Losh wrote: Rewind units on tape drives? If there's no access check done, and I open the rewind unit as joe-smoe? The close code is what does the rewind, and you don't have enough knowledge to know if the tape was opened r/w there. Which brings up the idea of passing fp-fd_flags to VOP_CLOSE()... Looking at the calls to VOP_CLOSE, there's either a flags variable, or the fmode variable I mentioned before, being passed as the second parameter. I haven't checked where this comes from in all cases, but when vn_closefile gets called, the value of this parameter is fp-f_flag. Similarly, when an open cannot be completed, the value is fmode. In other words, it looks like the flags are already there. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Samsung SPH-I500 (Palm/Phone) CDMA Modem
I bought one of these a while back, and just got a cable that I can carry with my Laptop. I get the following: Nov 1 19:57:31 lerlaptop kernel: ucom0: SAMSUNG Electronics Co.,Ltd. SAMSUNG CDMA Technologies, rev 1.01/0.00, addr 2, iclass 2/2 Nov 1 19:57:31 lerlaptop kernel: ucom0: data interface 1, has CM over data, has break Nov 1 19:57:36 lerlaptop kernel: ucom0: could not set data multiplex mode Nov 1 19:57:36 lerlaptop kernel: device_probe_and_attach: ucom0 attach returned 6 Nov 1 19:57:36 lerlaptop kernel: ugen0: SAMSUNG Electronics Co.,Ltd. SAMSUNG CDMA Technologies, rev 1.01/0.00, addr 2 ^C$ I'm wondering if any of the UMODEM guru's can decode this, (or ask me for more info) so I can use this phone as a modem. This is on -CURRENT from a week or so ago. Thanks! LER -- Larry Rosenman, Sr. Network Engineer, Internet America, Inc. E-Mail: [EMAIL PROTECTED] Phone: +1 214-861-2571, Fax: 214-861-2663 US Mail: 350 N. St. Paul, Suite 3000, Dallas, TX 75201 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
