Re: devfs doesn't set access rights
On Tue, Dec 13, 2005 at 05:37:09PM +0100, [LoN]Kamikaze wrote: On my FreeBSD 6-stable (the last build is less then 24hours ago) my devfs doesn't apply permissions set in /etc/devfs.conf when I attach new devices. I have to call: /etc/rc.d/devfs restart manually for the settings to be applied. This is rather uncomfortable in some cases (especially with my PDA). I don't know weather this is the normal behaviour, anyway if it is, shouldn't devfs be restarted automatically as soon as external devices (usb, firewire, ir) are attached? This is normal. devfs.conf is for boot only, you need devfs.rules for runtime. Unfortunatly, the documentation of this fact and the docuementation of devfs.rules sucks. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpHtHu8smvld.pgp Description: PGP signature
Re: devfs doesn't set access rights
On Tue, Dec 13, 2005 at 05:37:09PM +0100, [LoN]Kamikaze wrote:
On my FreeBSD 6-stable (the last build is less then 24hours ago) my
devfs doesn't apply permissions set in /etc/devfs.conf when I attach new
devices. I have to call:
/etc/rc.d/devfs restart
manually for the settings to be applied. This is rather uncomfortable in
some cases (especially with my PDA).
I don't know weather this is the normal behaviour, anyway if it is,
shouldn't devfs be restarted automatically as soon as external devices
(usb, firewire, ir) are attached?
It is the normal behaviour, /etc/rc.d/devfs is a little script that
parse /etc/devfs.conf and according to it and what it find in /dev it
set permissions or create links, it's purely static.
One possibility is to call /etc/rc.d/devfs when a device is attached
in /etc/devd.conf (take a look at devd(8) and devd.conf(5))
For exemple, I have something like this in my /etc/devd.conf :
attach 100 {
device-name umass[0-9]+ ;
action /bin/sleep 3; /etc/rc.d/devfs restart ;
};
attach : what kind of event
100 : as usual, for ordering rules
device-name ... : the device concerned
action ... : what to do, here I use sleep, because action is called
when the attach event arrives, not when the device node is created.
There maybe a better way, but it works© ;)
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
([EMAIL PROTECTED] | [EMAIL PROTECTED])
pgpk9kzQzAGwW.pgp
Description: PGP signature
Re: devfs doesn't set access rights
It's a simple and working solution and I think it simply should be made
default for ALL attach events. To me it makes more sense than having 2
different systems for the same thing.
Anyway, now I'm going to set up a devfs.rules (and learn a new different
syntax for doing exactly the same thing). This looks like something that
could have been in the unix haters handbook.
Brooks Davis wrote:
This is normal. devfs.conf is for boot only, you need devfs.rules for
runtime. Unfortunatly, the documentation of this fact and the
docuementation of devfs.rules sucks.
-- Brooks
Marwan Burelle wrote:
One possibility is to call /etc/rc.d/devfs when a device is attached
in /etc/devd.conf (take a look at devd(8) and devd.conf(5))
For exemple, I have something like this in my /etc/devd.conf :
attach 100 {
device-name umass[0-9]+ ;
action /bin/sleep 3; /etc/rc.d/devfs restart ;
};
attach : what kind of event
100 : as usual, for ordering rules
device-name ... : the device concerned
action ... : what to do, here I use sleep, because action is called
when the attach event arrives, not when the device node is created.
There maybe a better way, but it works© ;)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devfs doesn't set access rights
On Tuesday 13 December 2005 11:54 am, Marwan Burelle wrote:
On Tue, Dec 13, 2005 at 05:37:09PM +0100, [LoN]Kamikaze wrote:
On my FreeBSD 6-stable (the last build is less then 24hours ago)
my devfs doesn't apply permissions set in /etc/devfs.conf when I
attach new devices. I have to call:
/etc/rc.d/devfs restart
manually for the settings to be applied. This is rather
uncomfortable in some cases (especially with my PDA).
I don't know weather this is the normal behaviour, anyway if it
is, shouldn't devfs be restarted automatically as soon as
external devices (usb, firewire, ir) are attached?
It is the normal behaviour, /etc/rc.d/devfs is a little script that
parse /etc/devfs.conf and according to it and what it find in /dev
it set permissions or create links, it's purely static.
One possibility is to call /etc/rc.d/devfs when a device is
attached in /etc/devd.conf (take a look at devd(8) and
devd.conf(5))
For exemple, I have something like this in my /etc/devd.conf :
attach 100 {
device-name umass[0-9]+ ;
action /bin/sleep 3; /etc/rc.d/devfs restart ;
};
attach : what kind of event
100 : as usual, for ordering rules
device-name ... : the device concerned
action ... : what to do, here I use sleep, because action is
called when the attach event arrives, not when the device node is
created.
There maybe a better way, but it works© ;)
You should be using /etc/devfs.rules
Search the mailing list for examples and setup.
--
Anish Mistry
pgp9aPnG2LVym.pgp
Description: PGP signature
Re: devfs doesn't set access rights
Date: Tue, 13 Dec 2005 08:49:47 -0800 From: Brooks Davis [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] On Tue, Dec 13, 2005 at 05:37:09PM +0100, [LoN]Kamikaze wrote: On my FreeBSD 6-stable (the last build is less then 24hours ago) my devfs doesn't apply permissions set in /etc/devfs.conf when I attach new devices. I have to call: /etc/rc.d/devfs restart manually for the settings to be applied. This is rather uncomfortable in some cases (especially with my PDA). I don't know weather this is the normal behaviour, anyway if it is, shouldn't devfs be restarted automatically as soon as external devices (usb, firewire, ir) are attached? This is normal. devfs.conf is for boot only, you need devfs.rules for runtime. Unfortunatly, the documentation of this fact and the docuementation of devfs.rules sucks. Brooks, You are being entirely too kind. The documentation for the practical use of devfs at all sucks! Nothing I could find in the handbook, either. It's a classic case of documentation written by programmers in that the author can't look at his software from the standpoint of someone who does not know anything about it. Good documentation really needs to be written by someone sitting on the outside of the development process. But this is a huge problem for commercial applications where they actually hire writers, let alone for a volunteer project. I thought that the devfs.rules page was pretty helpful, but neither the devfs(8) nor the devfs(5) man pages mention either devfs.conf or devfs.rules in SEE ALSO (although devfs.rules is mentioned in FILES). No indication of how to use it or that there is actually a man page for it. No mention of devfs.conf at all. devfs(5) provides no clue at all that devfs does this sort of thing, either. While much of the contents of devfs.rules made little sense to me, it was enough for me to do what I was trying to do and it works fine. I also had to read /etc/rc.d/devfs in order to get it right as the comments in /etc/defaults/rc.conf are wrong and/or incomplete. But the real problem is finding the man page at all. Guess I'll try putting something together. Other than putting it in a PR, should I do anything else with it? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devfs doesn't set access rights
On Tue, Dec 13, 2005 at 06:19:47PM +0100, [LoN]Kamikaze wrote: It's a simple and working solution and I think it simply should be made default for ALL attach events. To me it makes more sense than having 2 different systems for the same thing. Anyway, now I'm going to set up a devfs.rules (and learn a new different syntax for doing exactly the same thing). This looks like something that could have been in the unix haters handbook. The devfs.conf method is inappropriate for runtime because if you don't do this in the kernel (as devfs(8) does) there is a race where the device initially has the wrong permissions. IMO, devfs.conf should either be taken out and shot or a parser to turn it into devfs(8) rules should be written. The current situation is utterly lame. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpEo7pb3bFu4.pgp Description: PGP signature
Re: devfs doesn't set access rights
On Tue, Dec 13, 2005 at 08:49:47AM -0800, Brooks Davis wrote: On Tue, Dec 13, 2005 at 05:37:09PM +0100, [LoN]Kamikaze wrote: On my FreeBSD 6-stable (the last build is less then 24hours ago) my devfs doesn't apply permissions set in /etc/devfs.conf when I attach new devices. I have to call: /etc/rc.d/devfs restart manually for the settings to be applied. This is rather uncomfortable in some cases (especially with my PDA). I don't know weather this is the normal behaviour, anyway if it is, shouldn't devfs be restarted automatically as soon as external devices (usb, firewire, ir) are attached? This is normal. devfs.conf is for boot only, you need devfs.rules for runtime. Unfortunatly, the documentation of this fact and the docuementation of devfs.rules sucks. Hmm, it's quite explicitly mentioned in the manual pages for devfs.conf and devfs.rules. Feel free to suggest improvements... Roland -- R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text. public key: http://www.xs4all.nl/~rsmith/pubkey.txt pgpKkmIhbIynk.pgp Description: PGP signature
Re: devfs doesn't set access rights
On Tue, Dec 13, 2005 at 09:37:13AM -0800, Kevin Oberman wrote: snip You are being entirely too kind. The documentation for the practical use of devfs at all sucks! Nothing I could find in the handbook, either. It's a classic case of documentation written by programmers in that the author can't look at his software from the standpoint of someone who does not know anything about it. Good documentation really needs to be written by someone sitting on the outside of the development process. But this is a huge problem for commercial applications where they actually hire writers, let alone for a volunteer project. The manual pages for devfs.conf and devfs.rules were definitely written on the outside. :-) I thought that the devfs.rules page was pretty helpful, but neither the devfs(8) nor the devfs(5) man pages mention either devfs.conf or devfs.rules in SEE ALSO (although devfs.rules is mentioned in FILES). No indication of how to use it or that there is actually a man page for it. No mention of devfs.conf at all. devfs(5) provides no clue at all that devfs does this sort of thing, either. Listing devfs.(conf|rules) in the SEE ALSO sections of devfs(5|8) sounds like a good idea. Guess I'll try putting something together. Other than putting it in a PR, should I do anything else with it? Putting in a PR, preferredly with a patch for the relevant manual pages, would be fine, I think. Roland -- R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text. public key: http://www.xs4all.nl/~rsmith/pubkey.txt pgpkaTjd08DqK.pgp Description: PGP signature
Re: devfs doesn't set access rights
Date: Tue, 13 Dec 2005 11:21:43 -0800 From: Brooks Davis [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] On Tue, Dec 13, 2005 at 07:04:18PM +0100, Roland Smith wrote: On Tue, Dec 13, 2005 at 08:49:47AM -0800, Brooks Davis wrote: On Tue, Dec 13, 2005 at 05:37:09PM +0100, [LoN]Kamikaze wrote: On my FreeBSD 6-stable (the last build is less then 24hours ago) my devfs doesn't apply permissions set in /etc/devfs.conf when I attach new devices. I have to call: /etc/rc.d/devfs restart manually for the settings to be applied. This is rather uncomfortable in some cases (especially with my PDA). I don't know weather this is the normal behaviour, anyway if it is, shouldn't devfs be restarted automatically as soon as external devices (usb, firewire, ir) are attached? This is normal. devfs.conf is for boot only, you need devfs.rules for runtime. Unfortunatly, the documentation of this fact and the docuementation of devfs.rules sucks. Hmm, it's quite explicitly mentioned in the manual pages for devfs.conf and devfs.rules. Feel free to suggest improvements... 90% of the problem is the existence of devfs.conf. devfs(8) appears capable of everything it does, but we still have two ways to do it which is gratuitously confusing. The devfs(8) documentation is lacking in a complete, working example, any documentation of the rc.conf variables (which also aren't documented in rc.conf(5) either), and any mention of that the purpose or usage of lines like: [devfsrules_unhide_basic=2] Thee is clearly the big issues, but devfs.conf seems to have one capability that devfs.rules lacks...the ability to create symlinks in the devfs. Lots of folks create symlinks to /dev/cdrom and/or /dev/dvd, among others and I can't see any way to make devfs.rules do this. I suspect that the capability could be added, though, which would make devfs.conf totally redundant. I have been hacking away at the various devd and devfs man pages this morning to make them a bit better. /etc/defaults/rc.conf and rc.conf(5) also need to be fixed. (Those are next on my hit list.) Setting the mode of a device node really ought to be trivial, but last time I looked at it I was clearly missing something and couldn't get it working. I decided the device in question really ought to be attached at boot and thus gave up and used devfs.conf since I had productive work to do. Some cook easy to use cookbook example would be really helpful for those who don't have time to figure out all the details. Comparativly few people will want to do anything more than make a device or two more accessable. I have not had any problem setting the mode of devices in devfs.rules. In fact, at this time, it's the only thing I use devfs.rules for. I thought that the example in devfs.rules(5) was pretty clear and I just added them (I had a couple) and they worked! It may be setting the mode (or anything else) at boot time as opposed to when a devfs entry is created on the fly does not work correctly (and, hence, the need for devfs.conf). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devfs doesn't set access rights
Well, here are my conclusions. 1) The manpage for devfs.rules should mention that you have to set devfs_system_ruleset=yourruleset in /etc/rc.conf . I didn't see it anywhere. 2) I have transferred all the rules in /etc/devfs.conf to /etc/devfs.rules, because I don't like to have 2 solutions for one task and because of the race condition mentioned in this list. 3) There is one kind of thing I cannot do in /etc/devfs.rules, creating links. So I am still doing this in /etc/devfs.conf (links don't cause race conditions anyway, I hope). One would think that link ttyU0 pilot would simply be translated to ln -s /dev/ttyU0 /dev/pilot which would simply create the link and it would work as soon as a ttyU0 device (my PDA) is there. But instead it checks weather the device exists (of course it doesn't since I didn't press the hotsync button during boot) and omits the creation of the link. So either the behaviour of /etc/rc.d/devfs has to be changed or it has to be dumped entirely and /sbin/devfs has to implement a way to create links (the solution I would prefer). - Dominic ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devfs doesn't set access rights
Here is a small patch for /etc/rc.d/devfs which makes it behave the way
I suggested in my last mail.
--- devfs.old Tue Dec 13 20:58:52 2005
+++ devfs Tue Dec 13 21:00:57 2005
@@ -43,8 +43,8 @@
cd /dev
while read action device parameter; do
case ${action} in
- l*) if [ -c ${device} -a ! -e ${parameter}
]; then
- ln -fs ${device} ${parameter}
+ l*) if [ ! -e ${parameter} ]; then
+ ln -s ${device} ${parameter}
fi
;;
o*) if [ -c ${device} ]; then
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devfs doesn't set access rights
On Tue, Dec 13, 2005 at 11:21:43AM -0800, Brooks Davis wrote: snip This is normal. devfs.conf is for boot only, you need devfs.rules for runtime. Unfortunatly, the documentation of this fact and the docuementation of devfs.rules sucks. Hmm, it's quite explicitly mentioned in the manual pages for devfs.conf and devfs.rules. Feel free to suggest improvements... 90% of the problem is the existence of devfs.conf. devfs(8) appears capable of everything it does, but we still have two ways to do it which is gratuitously confusing. Hmm, I can mostly agree with that. The only real use I can think of for devfs.conf is when the devfs binary is corrupt. The devfs(8) documentation is lacking in a complete, working example, What's wrong with the EXAMPLES section in devfs(8)? any documentation of the rc.conf variables (which also aren't documented in rc.conf(5) either), and any mention of that the purpose or usage of lines like: [devfsrules_unhide_basic=2] See devfs.rules(5), third para of DESCRIPTION. I agree it could use an example, and some explanation that you have to enable the ruleset in /etc/rc.conf. There is an example on my website: http://www.xs4all.nl/~rsmith/freebsd/#hotplug Following is a patch for devfs.rules.5. Comments? Otherwise I'll submit it. -- devfs.rules.5 patch -- --- devfs.rules.5 2005/12/13 19:59:29 1.6 +++ devfs.rules.5 2005/12/13 20:16:40 @@ -24,7 +24,7 @@ .\ .\ $FreeBSD: /repoman/r/ncvs/src/share/man/man5/devfs.rules.5,v 1.2.4.1 2005/07/27 12:03:48 keramida Exp $ .\ -.Dd May 17, 2005 +.Dd Dec 13, 2005 .Dt DEVFS.RULES 5 .Os .Sh NAME @@ -72,8 +72,22 @@ .Dq Li usb group, the following rule may be used: .Pp +.Dl [localrules=10] .Dl add path 'da*s*' mode 0660 group usb .Pp +The first line declares and starts a new ruleset, with the name +.Va localrules +and the number 10. Rulesets should have a unique name and number. All +rules that follow a ruleset declaration belong to that ruleset, untill a +new ruleset is started. This ruleset has to be enabled in +.Pa /etc/rc.conf +to be the ruleset for the +.Pa /dev +filesystem. This is done by putting the following line in +.Pa /etc/rc.conf : +.Pp +.Dl devfs_system_ruleset=localrules +.Pp To make all the .Xr uscanner 4 devices accessible to their owner and the @@ -81,6 +95,7 @@ group, a similar rule may be used: .Pp .Dl add path 'uscanner*' mode 0660 group usb +.Pp .Sh SEE ALSO .Xr glob 3 , .Xr devfs 5 , -- devfs.rules.5 patch -- Setting the mode of a device node really ought to be trivial, but last time I looked at it I was clearly missing something and couldn't get it working. I decided the device in question really ought to be attached at boot and thus gave up and used devfs.conf since I had productive work to do. Some cook easy to use cookbook example would be really helpful for those who don't have time to figure out all the details. Maybe my freebsd page can help. Most of the things I learned while configuring FreeBSD are documented here. http://www.xs4all.nl/~rsmith/freebsd Comparativly few people will want to do anything more than make a device or two more accessable. Agreed. But the mechanism is more general because devfs can be used in multiple places (e.g. jails). Roland -- R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text. public key: http://www.xs4all.nl/~rsmith/pubkey.txt pgpQ1FYy2ELwL.pgp Description: PGP signature
Re: devfs doesn't set access rights
On Tue, Dec 13, 2005 at 08:44:50PM +0100, [LoN]Kamikaze wrote: Well, here are my conclusions. 1) The manpage for devfs.rules should mention that you have to set devfs_system_ruleset=yourruleset in /etc/rc.conf . I didn't see it anywhere. Agreed. I've posted a patch in this thread for that. If there are no comments, I'll send-pr it. snip 3) There is one kind of thing I cannot do in /etc/devfs.rules, creating links. So I am still doing this in /etc/devfs.conf (links don't cause race conditions anyway, I hope). Maybe devd could be used for that. One would think that link ttyU0 pilot would simply be translated to ln -s /dev/ttyU0 /dev/pilot which would simply create the link and it would work as soon as a ttyU0 device (my PDA) is there. But instead it checks weather the device exists (of course it doesn't since I didn't press the hotsync button during boot) and omits the creation of the link. So either the behaviour of /etc/rc.d/devfs has to be changed or it has to be dumped entirely and /sbin/devfs has to implement a way to create links (the solution I would prefer). And maybe there should be a combination with devd? Roland -- R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text. public key: http://www.xs4all.nl/~rsmith/pubkey.txt pgp8MKZenux7q.pgp Description: PGP signature
Re: devfs doesn't set access rights
I hacked together the current mess over two and a half years ago for one simple reason, so that the functionality that used to be in the system prior to rcNG would still be there. Since then, we've had roughly 18 rounds of this same discussion, but no one has actually stepped up to do the work of converting /etc/rc.d/devfs to use rules. (Oh, and as someone else already pointed out, whatever you replace it with has to be able to add symlinks as well.) If someone wants to do that, great! If not, whining about it isn't really all that useful of an exercise. Everyone already knows it needs to be updated. Same goes for the documentation btw. Patches are welcome, complaining that it should be better is not. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devfs doesn't set access rights
On Tue, Dec 13, 2005 at 09:22:34PM +0100, Roland Smith wrote: On Tue, Dec 13, 2005 at 11:21:43AM -0800, Brooks Davis wrote: snip This is normal. devfs.conf is for boot only, you need devfs.rules for runtime. Unfortunatly, the documentation of this fact and the docuementation of devfs.rules sucks. Hmm, it's quite explicitly mentioned in the manual pages for devfs.conf and devfs.rules. Feel free to suggest improvements... 90% of the problem is the existence of devfs.conf. devfs(8) appears capable of everything it does, but we still have two ways to do it which is gratuitously confusing. Hmm, I can mostly agree with that. The only real use I can think of for devfs.conf is when the devfs binary is corrupt. That seems like a non issue. In that case you're in recovery mode and presumably need to know how to drive chown and chmod. :) The devfs(8) documentation is lacking in a complete, working example, What's wrong with the EXAMPLES section in devfs(8)? It's fine. Referring to devfs(8) was poor word choice on my part. I meant the system as a whole including devfs.rules. any documentation of the rc.conf variables (which also aren't documented in rc.conf(5) either), and any mention of that the purpose or usage of lines like: [devfsrules_unhide_basic=2] See devfs.rules(5), third para of DESCRIPTION. I agree it could use an example, and some explanation that you have to enable the ruleset in /etc/rc.conf. That's quite easy to miss. I saw the bit about comments and my eyes glazed over and skipped the rest. Breaking out the paragraph into bullets might be an improvement. There is an example on my website: http://www.xs4all.nl/~rsmith/freebsd/#hotplug Following is a patch for devfs.rules.5. Comments? Otherwise I'll submit it. Content looks good to me. -- devfs.rules.5 patch -- --- devfs.rules.5 2005/12/13 19:59:29 1.6 +++ devfs.rules.5 2005/12/13 20:16:40 @@ -24,7 +24,7 @@ .\ .\ $FreeBSD: /repoman/r/ncvs/src/share/man/man5/devfs.rules.5,v 1.2.4.1 2005/07/27 12:03:48 keramida Exp $ .\ -.Dd May 17, 2005 +.Dd Dec 13, 2005 .Dt DEVFS.RULES 5 .Os .Sh NAME @@ -72,8 +72,22 @@ .Dq Li usb group, the following rule may be used: .Pp +.Dl [localrules=10] .Dl add path 'da*s*' mode 0660 group usb .Pp +The first line declares and starts a new ruleset, with the name +.Va localrules +and the number 10. Rulesets should have a unique name and number. All +rules that follow a ruleset declaration belong to that ruleset, untill a +new ruleset is started. This ruleset has to be enabled in +.Pa /etc/rc.conf +to be the ruleset for the +.Pa /dev +filesystem. This is done by putting the following line in +.Pa /etc/rc.conf : +.Pp +.Dl devfs_system_ruleset=localrules From looking in rc.conf(5), I think this should be: .Pa /etc/rc.conf : .Bd -literal devfs_system_ruleset=localrules .Ed +.Pp To make all the .Xr uscanner 4 devices accessible to their owner and the @@ -81,6 +95,7 @@ group, a similar rule may be used: .Pp .Dl add path 'uscanner*' mode 0660 group usb +.Pp I think this is unnecessary. It's certainly not common practice. .Sh SEE ALSO .Xr glob 3 , .Xr devfs 5 , -- devfs.rules.5 patch -- Setting the mode of a device node really ought to be trivial, but last time I looked at it I was clearly missing something and couldn't get it working. I decided the device in question really ought to be attached at boot and thus gave up and used devfs.conf since I had productive work to do. Some cook easy to use cookbook example would be really helpful for those who don't have time to figure out all the details. Maybe my freebsd page can help. Most of the things I learned while configuring FreeBSD are documented here. http://www.xs4all.nl/~rsmith/freebsd The example you site looks like excellent handbook fodder. Comparativly few people will want to do anything more than make a device or two more accessable. Agreed. But the mechanism is more general because devfs can be used in multiple places (e.g. jails). Definitely. The full features look quite cool and useful. My concern is simply that it's easy to find out how to do the common thing without having to understand all the complex things you can do. Thanks for writing this manpage and working to improve it! -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpA0dWeZeoY2.pgp Description: PGP signature
Re: devfs doesn't set access rights
On Tue, Dec 13, 2005 at 12:55:39PM -0800, Brooks Davis wrote: snip What's wrong with the EXAMPLES section in devfs(8)? It's fine. Referring to devfs(8) was poor word choice on my part. I meant the system as a whole including devfs.rules. any documentation of the rc.conf variables (which also aren't documented in rc.conf(5) either), and any mention of that the purpose or usage of lines like: [devfsrules_unhide_basic=2] See devfs.rules(5), third para of DESCRIPTION. I agree it could use an example, and some explanation that you have to enable the ruleset in /etc/rc.conf. That's quite easy to miss. I saw the bit about comments and my eyes glazed over and skipped the rest. Breaking out the paragraph into bullets might be an improvement. There is an example on my website: http://www.xs4all.nl/~rsmith/freebsd/#hotplug Following is a patch for devfs.rules.5. Comments? Otherwise I'll submit it. Content looks good to me. snip From looking in rc.conf(5), I think this should be: .Pa /etc/rc.conf : .Bd -literal devfs_system_ruleset=localrules .Ed Ok, I'll incorporate that, and send-pr it. +.Pp To make all the .Xr uscanner 4 devices accessible to their owner and the @@ -81,6 +95,7 @@ group, a similar rule may be used: .Pp .Dl add path 'uscanner*' mode 0660 group usb +.Pp I think this is unnecessary. It's certainly not common practice. It's just another example. .Sh SEE ALSO .Xr glob 3 , .Xr devfs 5 , -- devfs.rules.5 patch -- Setting the mode of a device node really ought to be trivial, but last time I looked at it I was clearly missing something and couldn't get it working. I decided the device in question really ought to be attached at boot and thus gave up and used devfs.conf since I had productive work to do. Some cook easy to use cookbook example would be really helpful for those who don't have time to figure out all the details. Maybe my freebsd page can help. Most of the things I learned while configuring FreeBSD are documented here. http://www.xs4all.nl/~rsmith/freebsd The example you site looks like excellent handbook fodder. Do you want to submit it? I won't have time to do it before mid-januari at least. Comparativly few people will want to do anything more than make a device or two more accessable. Agreed. But the mechanism is more general because devfs can be used in multiple places (e.g. jails). Definitely. The full features look quite cool and useful. My concern is simply that it's easy to find out how to do the common thing without having to understand all the complex things you can do. Thanks for writing this manpage and working to improve it! Thanks! Actually, my motivation for writing the manpages was to stop the tide of how do I configure devfs postings on -questions. Unfortunately, once you understand the details of the system well enough to document it, some of the details will seem so obvious that you don't document them. :-) Roland -- R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text. public key: http://www.xs4all.nl/~rsmith/pubkey.txt pgpyah6nj8gvH.pgp Description: PGP signature
Re: devfs doesn't set access rights
On Tue, Dec 13, 2005 at 12:23:26PM -0500, Anish Mistry wrote: There maybe a better way, but it works© ;) You should be using /etc/devfs.rules Search the mailing list for examples and setup. Yes, I know, some month ago I wrote a little documentation (in french [1]) for using USB keys on a FreeBSD worstation. Someone point me out to devfs.rules, but at that time I couldn't find any clear documentation, nor any clear way of doing some more complex things. My goal was to simulate Linux+Gnome behaviour when USB key are plugged, that is, transparently mount it with the user id so that Gnome desktop shows it with an appropriate icon[2]. Using devfs.conf was a simple way of fixing permissions but in the context not the only one. I used devd.conf, since I want some other task to do, mainly a script that find if a user is logged with X, and mount the right device with its id, this involve also testing if the device use da0 or da0s1 and also manage the possibility of plugin more than one umass devices at the same time. In that context using devfs.conf or devfs.rules doesn't realy change (as a user point of view, in particular when you don't realy know the difference.) I know now that I was wrong, but as the current discussion shows, there is (was ? ;) a lack of good documentation on the subject. [1] : http://www.lri.fr/~burelle/BSD/USBKey-FreeBSD.html [2] : My starting was point here : http://caia.swin.edu.au/reports/041130A/ -- Marwan Burelle, http://www.lri.fr/~burelle ( [EMAIL PROTECTED] | [EMAIL PROTECTED] ) http://www.cduce.org pgpohE2eK1Vgi.pgp Description: PGP signature
Re: devfs doesn't set access rights
On 12/14/05 06:44, [LoN]Kamikaze wrote:
3)
There is one kind of thing I cannot do in /etc/devfs.rules, creating
links. So I am still doing this in /etc/devfs.conf (links don't cause
race conditions anyway, I hope).
One would think that link ttyU0 pilot would simply be translated to
ln -s /dev/ttyU0 /dev/pilot which would simply create the link and it
would work as soon as a ttyU0 device (my PDA) is there. But instead it
checks weather the device exists (of course it doesn't since I didn't
press the hotsync button during boot) and omits the creation of the link.
Note that while for you it might be sufficient to have a hard coded link
from /dev/pilot to /dev/ttyU0, that is not necessarily the case if you
have multiple USB serial gadgets.
The way I handled it is by using an entry in /etc/usbd.conf:
#
# Fixup permissions for Palm Handheld ucom devices
# (set here and not in devfs.rules since we only want to apply
# the change to Palm com ports, not all USB com ports)
device PalmHandheld
devname ucom[0-9]+
vendor 0x0830
attach /bin/chmod 0666 /dev/${DEVNAME} ; /bin/ln -s
/dev/${DEVNAME} /dev/pilot
detach rm -f /dev/pilot
Having said that, it would be great to be able to create links from
devfs.rules - I'd certainly use it for my /dev/cdrom entry!
Cheers,
/Johny
--
Johny Mattsson - Making IT work ,-. ,-. ,-. When all else fails,
http://www.earthmagic.org _.' `-' `-' Murphy's Law still works!
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devfs doesn't set access rights
On Tue, Dec 13, 2005 at 10:31:21PM +0100, Roland Smith wrote: On Tue, Dec 13, 2005 at 12:55:39PM -0800, Brooks Davis wrote: snip What's wrong with the EXAMPLES section in devfs(8)? It's fine. Referring to devfs(8) was poor word choice on my part. I meant the system as a whole including devfs.rules. any documentation of the rc.conf variables (which also aren't documented in rc.conf(5) either), and any mention of that the purpose or usage of lines like: [devfsrules_unhide_basic=2] See devfs.rules(5), third para of DESCRIPTION. I agree it could use an example, and some explanation that you have to enable the ruleset in /etc/rc.conf. That's quite easy to miss. I saw the bit about comments and my eyes glazed over and skipped the rest. Breaking out the paragraph into bullets might be an improvement. There is an example on my website: http://www.xs4all.nl/~rsmith/freebsd/#hotplug Following is a patch for devfs.rules.5. Comments? Otherwise I'll submit it. Content looks good to me. snip From looking in rc.conf(5), I think this should be: .Pa /etc/rc.conf : .Bd -literal devfs_system_ruleset=localrules .Ed Ok, I'll incorporate that, and send-pr it. Great. +.Pp To make all the .Xr uscanner 4 devices accessible to their owner and the @@ -81,6 +95,7 @@ group, a similar rule may be used: .Pp .Dl add path 'uscanner*' mode 0660 group usb +.Pp I think this is unnecessary. It's certainly not common practice. It's just another example. I was referring to the .Pp before the .Sh below. .Sh SEE ALSO .Xr glob 3 , .Xr devfs 5 , -- devfs.rules.5 patch -- Setting the mode of a device node really ought to be trivial, but last time I looked at it I was clearly missing something and couldn't get it working. I decided the device in question really ought to be attached at boot and thus gave up and used devfs.conf since I had productive work to do. Some cook easy to use cookbook example would be really helpful for those who don't have time to figure out all the details. Maybe my freebsd page can help. Most of the things I learned while configuring FreeBSD are documented here. http://www.xs4all.nl/~rsmith/freebsd The example you site looks like excellent handbook fodder. Do you want to submit it? I won't have time to do it before mid-januari at least. Comparativly few people will want to do anything more than make a device or two more accessable. Agreed. But the mechanism is more general because devfs can be used in multiple places (e.g. jails). Definitely. The full features look quite cool and useful. My concern is simply that it's easy to find out how to do the common thing without having to understand all the complex things you can do. Thanks for writing this manpage and working to improve it! Thanks! Actually, my motivation for writing the manpages was to stop the tide of how do I configure devfs postings on -questions. Unfortunately, once you understand the details of the system well enough to document it, some of the details will seem so obvious that you don't document them. :-) Yes, that's always a problem. I haven't mastered the necessary xen-like state where I can forget what I know when I'm reading my own work. :) -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpup3r5vX2OI.pgp Description: PGP signature
Re: devfs doesn't set access rights
I agree that a more flexible approach is generally better, but since
it's not necessary I don't want to create an extra entry in my
/etc/usbd.conf (one more file to worry about during mergemaster).
Thus I think the best solution would be to dump devfs.conf and
/etc/rc.d/devfs entirely (or leave it optional for backwards
compatibility) and give devfs the ability to create links.
I have a dislike for inconsistent solutions and I think most people here
share this dislike. It's just what happens when software grows. Sooner
or later you get to the point where you should throw away 80% of what's
there and turn the rest into something that does what needs to be done.
Johny Mattsson wrote:
Note that while for you it might be sufficient to have a hard coded link
from /dev/pilot to /dev/ttyU0, that is not necessarily the case if you
have multiple USB serial gadgets.
The way I handled it is by using an entry in /etc/usbd.conf:
#
# Fixup permissions for Palm Handheld ucom devices
# (set here and not in devfs.rules since we only want to apply
# the change to Palm com ports, not all USB com ports)
device PalmHandheld
devname ucom[0-9]+
vendor 0x0830
attach /bin/chmod 0666 /dev/${DEVNAME} ; /bin/ln -s
/dev/${DEVNAME} /dev/pilot
detach rm -f /dev/pilot
Having said that, it would be great to be able to create links from
devfs.rules - I'd certainly use it for my /dev/cdrom entry!
Cheers,
/Johny
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devfs doesn't set access rights
On Wed, Dec 14, 2005 at 12:31:52AM +0100, [LoN]Kamikaze wrote: I agree that a more flexible approach is generally better, but since it's not necessary I don't want to create an extra entry in my /etc/usbd.conf (one more file to worry about during mergemaster). IIRC, usbd is/will be deprecated in favor of devd. Thus I think the best solution would be to dump devfs.conf and /etc/rc.d/devfs entirely (or leave it optional for backwards compatibility) and give devfs the ability to create links. Yeah, I agree that would be best. I'd be willing to look into that, but not before mid-januari. I have a dislike for inconsistent solutions and I think most people here share this dislike. It's just what happens when software grows. Sooner or later you get to the point where you should throw away 80% of what's there and turn the rest into something that does what needs to be done. Well, an adequate solution now always beats a perfect solution later. :-) Roland -- R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text. public key: http://www.xs4all.nl/~rsmith/pubkey.txt pgpcSQKd2w9pW.pgp Description: PGP signature
Re: devfs doesn't set access rights
On Tuesday 13 December 2005 05:26 pm, Johny Mattsson wrote:
On 12/14/05 06:44, [LoN]Kamikaze wrote:
3)
There is one kind of thing I cannot do in /etc/devfs.rules,
creating links. So I am still doing this in /etc/devfs.conf
(links don't cause race conditions anyway, I hope).
One would think that link ttyU0 pilot would simply be
translated to ln -s /dev/ttyU0 /dev/pilot which would simply
create the link and it would work as soon as a ttyU0 device (my
PDA) is there. But instead it checks weather the device exists
(of course it doesn't since I didn't press the hotsync button
during boot) and omits the creation of the link.
Note that while for you it might be sufficient to have a hard coded
link from /dev/pilot to /dev/ttyU0, that is not necessarily the
case if you have multiple USB serial gadgets.
The way I handled it is by using an entry in /etc/usbd.conf:
#
# Fixup permissions for Palm Handheld ucom devices
# (set here and not in devfs.rules since we only want to apply
# the change to Palm com ports, not all USB com ports)
device PalmHandheld
devname ucom[0-9]+
vendor 0x0830
attach /bin/chmod 0666 /dev/${DEVNAME} ; /bin/ln -s
/dev/${DEVNAME} /dev/pilot
detach rm -f /dev/pilot
Roland already mentioned this point, but usbd and usbd.conf have been
depreciated since 5.x. They WILL be going away in CURRENT (usbd.conf
no longer has any entries) once Ian gets a chance to review and
commit the patches. If you are in need of the release field for usb
devices on 5.x or 6.x check out:
http://www.freebsd.org/cgi/query-pr.cgi?pr=73799
--
Anish Mistry
pgpASt9Sd8KYu.pgp
Description: PGP signature
