BUS_PROBE_NOWILDCARD behaviour doesn't seem to match DEVICE_PROBE(9)
http://www.freebsd.org/cgi/man.cgi?query=DEVICE_PROBE&apropos=0&sektion=0&manpath=FreeBSD%208.2-RELEASE&format=html DEVICE_PROBE(9) has this to say about BUS_PROBE_NOWILDCARD: The driver expects its parent to tell it which children to manage and no probing is really done. The device only matches if its parent bus specifically said to use this driver. I interpreted this as meaning that if BUS_ADD_CHILD() is called with the name parameter specifying a driver then if that driver's probe method returns BUS_PROBE_NOWILDCARD the driver will match that device. However the logic in subr_bus.c is more strict; it will only match if the unit number if also specified. This seems overly strict to me, and there appears to be at least one case in-tree where a driver will never match due to this behaviour: http://svnweb.freebsd.org/base/head/sys/dev/iicbus/iicsmb.c?revision=227843&view=markup The iicsmb driver calls BUS_ADD_CHILD() from its identify method with a wildcarded unit number (-1) but the driver specified. It then returns BUS_PROBE_NOWILDCARD from its attach method(intending that it only claim the device created in the identify method), but that won't match. I want to use the exact same pattern in a new driver. The following patch allows this to work: diff --git a/sys/kern/subr_bus.c b/sys/kern/subr_bus.c index 1f3d4e8..7e48b0e 100644 --- a/sys/kern/subr_bus.c +++ b/sys/kern/subr_bus.c @@ -2015,7 +2015,7 @@ device_probe_child(device_t dev, device_t child) * in stone by the parent bus. */ if (result <= BUS_PROBE_NOWILDCARD && - child->flags & DF_WILDCARD) + !(child->flags & DF_FIXEDCLASS)) continue; best = dl; pri = result; This should be safe to do, as all devices that specified a unit number must have specified a driver, so this can't cause any devices to suddenly fail to match. I supposed that it theoretically could cause a driver to match a device that previously it wouldn't have, but I'm having trouble seeing how somebody could add a device of type "foo" and not expect the "foo" driver to attach. Any objections if I commit this? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Shell variables containing output redirects
Hello all!
I have a problem with port JBoss72, which tries to behave as long-standing
port jboss5:
http://svnweb.freebsd.org/ports/head/java/jboss5/files/jboss5.in?revision=302141&view=markup
In rc run script there is such line:
%%APP_SHORTNAME%%_logging="${%%APP_SHORTNAME%%_logging:-">>
${%%APP_SHORTNAME%%_logdir}/stdout.log 2>>
${%%APP_SHORTNAME%%_logdir}/stderr.log"}"
Which provides way to overwrite default log location in /etc/rc.conf.
But this not working at all, all these redirects treated as simple
parameters for run script.
I made small test, to show my problem:
#!/bin/sh
logfile="supposed-to-be.log"
log=">> ${logfile}"
echo "a1" >> ${logfile}
echo "a2" ${log}
cmd="echo \"a3\" ${log}"
echo $cmd
$cmd
more ${logfile}
Here's execution output:
# ./t1.sh
a2 >> supposed-to-be.log
echo "a3" >> supposed-to-be.log
"a3" >> supposed-to-be.log
a1
1. My question is - Which are correct way to specify such redirects to be
overridden?
2. tomcat6.in, rubyrep.in, tclhttpd.in, geoserver.in, and many more rc
scripts from ports are using something like this:
log_args=">> ${tclhttpd_stdout_log} 2>> ${tclhttpd_stderr_log} "
and after that use $log_args.
Are they silently broken, or am I missing something?
3. Should I build up $cmd, and run
eval "$cmd" - would this be nice ro dirty hack?
Thanks!
--
Regards,
Alexander Yerenkow
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Shell variables containing output redirects
On Jun 20, 2013, at 7:57 AM, Alexander Yerenkow wrote:
> Hello all!
>
> I have a problem with port JBoss72, which tries to behave as long-standing
> port jboss5:
>
> http://svnweb.freebsd.org/ports/head/java/jboss5/files/jboss5.in?revision=302141&view=markup
>
>
>
> In rc run script there is such line:
>
> %%APP_SHORTNAME%%_logging="${%%APP_SHORTNAME%%_logging:-">>
> ${%%APP_SHORTNAME%%_logdir}/stdout.log 2>>
> ${%%APP_SHORTNAME%%_logdir}/stderr.log"}"
>
> Which provides way to overwrite default log location in /etc/rc.conf.
>
> But this not working at all, all these redirects treated as simple
> parameters for run script.
>
> I made small test, to show my problem:
>
> #!/bin/sh
>
> logfile="supposed-to-be.log"
> log=">> ${logfile}"
> echo "a1" >> ${logfile}
> echo "a2" ${log}
> cmd="echo \"a3\" ${log}"
> echo $cmd
> $cmd
> more ${logfile}
>
> Here's execution output:
>
> # ./t1.sh
> a2 >> supposed-to-be.log
> echo "a3" >> supposed-to-be.log
> "a3" >> supposed-to-be.log
> a1
>
> 1. My question is - Which are correct way to specify such redirects to be
> overridden?
>
If you must have a conditional redirect in the above manner (in which the
redirect syntax is part of a variable):
to_foofile=">> foofile"
eval echo \"a1\" $to_foofile
The shell will do a first-pass on the arguments, so what "eval" sees as
arguments are:
echo "a1" >> foofile
And thus, eval does what it does best… evaluates the expressions as a set of
shell statements.
NOTE: The rc script probably assumed bash and was ported from another system
where /bin/sh was indeed bash (but in FreeBSD, /bin/sh is not bash and is much
more strict in adhering to POSIX standards).
However, I can't in all earnest recommend that approach as a method of
conditional logging when there are so many better solutions.
Here's one of my favorites for quick-and-dirty conditional logging:
===
#!/bin/sh
if : some condition to enable debugging; then
exec 3>>/tmp/log.stdout 4>>/tmp/log.stderr
else
exec 3>&1 4>&2
fi
echo "a1" 1>&3 2>&4
# "a1" ends up in /tmp/log.stdout
ls /nosuchfile 1>&3 2>&4
# You get in /tmp/log.stderr: "ls: /nosuchfile: No such file or
directory"
===
So rather than having to prefix "eval" to every command *and* escape all the
quotes and expansions… the above instead changes from (old) attempting to use a
conditional redirect syntax (by way of $logging variable) to (new/above) having
every command redirect stdout/stderr but having the destinations of the
redirect change based on some pre-condition.
> 2. tomcat6.in, rubyrep.in, tclhttpd.in, geoserver.in, and many more rc
> scripts from ports are using something like this:
>
> log_args=">> ${tclhttpd_stdout_log} 2>> ${tclhttpd_stderr_log} "
>
> and after that use $log_args.
>
> Are they silently broken, or am I missing something?
>
I would call that broken if the invocation line at the top of the script is
#!/bin/sh (it may not be broken if you instead see something like
"#!/usr/bin/env bash").
> 3. Should I build up $cmd, and run
> eval "$cmd" - would this be nice ro dirty hack?
>
Nah… just go through and replace "$log_args" with either "1>&3 2>&4" or ">&3
2>&4" (the leading 1 on ">&" in the first option is actually the implied
default, so you can omit it and go for the second option if you like; however
since you can't say "exec 3>&" and have to say "exec 3>&1", I tend to think the
first option is more explicitly-clear in what's going on with the
file-descriptors).
> Thanks!
>
No problem. Glad to help.
--
Devin
_
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Shell variables containing output redirects
On Jun 20, 2013, at 9:04 AM, Teske, Devin wrote:
>
> On Jun 20, 2013, at 7:57 AM, Alexander Yerenkow wrote:
>
>> Hello all!
>>
>> I have a problem with port JBoss72, which tries to behave as long-standing
>> port jboss5:
>>
>> http://svnweb.freebsd.org/ports/head/java/jboss5/files/jboss5.in?revision=302141&view=markup
>>
>>
>>
>> In rc run script there is such line:
>>
>> %%APP_SHORTNAME%%_logging="${%%APP_SHORTNAME%%_logging:-">>
>> ${%%APP_SHORTNAME%%_logdir}/stdout.log 2>>
>> ${%%APP_SHORTNAME%%_logdir}/stderr.log"}"
>>
>> Which provides way to overwrite default log location in /etc/rc.conf.
>>
>> But this not working at all, all these redirects treated as simple
>> parameters for run script.
>>
>> I made small test, to show my problem:
>>
>> #!/bin/sh
>>
>> logfile="supposed-to-be.log"
>> log=">> ${logfile}"
>> echo "a1" >> ${logfile}
>> echo "a2" ${log}
>> cmd="echo \"a3\" ${log}"
>> echo $cmd
>> $cmd
>> more ${logfile}
>>
>> Here's execution output:
>>
>> # ./t1.sh
>> a2 >> supposed-to-be.log
>> echo "a3" >> supposed-to-be.log
>> "a3" >> supposed-to-be.log
>> a1
>>
>> 1. My question is - Which are correct way to specify such redirects to be
>> overridden?
>>
>
> If you must have a conditional redirect in the above manner (in which the
> redirect syntax is part of a variable):
>
> to_foofile=">> foofile"
> eval echo \"a1\" $to_foofile
>
> The shell will do a first-pass on the arguments, so what "eval" sees as
> arguments are:
>
> echo "a1" >> foofile
>
> And thus, eval does what it does best… evaluates the expressions as a set of
> shell statements.
>
> NOTE: The rc script probably assumed bash and was ported from another system
> where /bin/sh was indeed bash (but in FreeBSD, /bin/sh is not bash and is
> much more strict in adhering to POSIX standards).
>
> However, I can't in all earnest recommend that approach as a method of
> conditional logging when there are so many better solutions.
>
> Here's one of my favorites for quick-and-dirty conditional logging:
>
> ===
>
> #!/bin/sh
>
> if : some condition to enable debugging; then
> exec 3>>/tmp/log.stdout 4>>/tmp/log.stderr
> else
> exec 3>&1 4>&2
> fi
>
> echo "a1" 1>&3 2>&4
> # "a1" ends up in /tmp/log.stdout
>
> ls /nosuchfile 1>&3 2>&4
> # You get in /tmp/log.stderr: "ls: /nosuchfile: No such file or
> directory"
>
> ===
>
Yeah… don't do that… the moment I hit send, it dawned on me that the extra
file-descriptor (however cute), is entire unnecessary…
===
#!/bin/sh
if : some condition to enable debugging; then
exec 1>>/tmp/log.stdout 2>>/tmp/log.stderr
fi
echo d1
# if debugging, goes to /tmp/log.stdout
# if no debugging, goes to console
ls /nosuchfile
# if debugging, an error goes to /tmp/log.stderr
# if no debugging, error goes to console
===
> So rather than having to prefix "eval" to every command *and* escape all the
> quotes and expansions… the above instead changes from (old) attempting to use
> a conditional redirect syntax (by way of $logging variable) to (new/above)
> having every command redirect stdout/stderr but having the destinations of
> the redirect change based on some pre-condition.
>
>
>
>> 2. tomcat6.in, rubyrep.in, tclhttpd.in, geoserver.in, and many more rc
>> scripts from ports are using something like this:
>>
>> log_args=">> ${tclhttpd_stdout_log} 2>> ${tclhttpd_stderr_log} "
>>
>> and after that use $log_args.
>>
>> Are they silently broken, or am I missing something?
>>
>
> I would call that broken if the invocation line at the top of the script is
> #!/bin/sh (it may not be broken if you instead see something like
> "#!/usr/bin/env bash").
>
>
>
>
>> 3. Should I build up $cmd, and run
>> eval "$cmd" - would this be nice ro dirty hack?
>>
>
> Nah… just go through and replace "$log_args" with either "1>&3 2>&4" or ">&3
> 2>&4" (the leading 1 on ">&" in the first option is actually the implied
> default, so you can omit it and go for the second option if you like; however
> since you can't say "exec 3>&" and have to say "exec 3>&1", I tend to think
> the first option is more explicitly-clear in what's going on with the
> file-descriptors).
>
Actually… you could potentially fix this with one line of code…
[ "$logging" ] && exec 1>>/tmp/log.stdout 2>>/tmp/log.stderr
And then go remove the "$logging" from the end of each line.
--
Devin
_
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.free
Re: Shell variables containing output redirects
On Jun 20, 2013, at 9:11 AM, Teske, Devin wrote:
>
> On Jun 20, 2013, at 9:04 AM, Teske, Devin wrote:
>
>>
>> On Jun 20, 2013, at 7:57 AM, Alexander Yerenkow wrote:
>>
>>> Hello all!
>>>
>>> I have a problem with port JBoss72, which tries to behave as long-standing
>>> port jboss5:
>>>
>>> http://svnweb.freebsd.org/ports/head/java/jboss5/files/jboss5.in?revision=302141&view=markup
>>>
>>>
>>>
>>> In rc run script there is such line:
>>>
>>> %%APP_SHORTNAME%%_logging="${%%APP_SHORTNAME%%_logging:-">>
>>> ${%%APP_SHORTNAME%%_logdir}/stdout.log 2>>
>>> ${%%APP_SHORTNAME%%_logdir}/stderr.log"}"
>>>
>>> Which provides way to overwrite default log location in /etc/rc.conf.
>>>
>>> But this not working at all, all these redirects treated as simple
>>> parameters for run script.
>>>
>>> I made small test, to show my problem:
>>>
>>> #!/bin/sh
>>>
>>> logfile="supposed-to-be.log"
>>> log=">> ${logfile}"
>>> echo "a1" >> ${logfile}
>>> echo "a2" ${log}
>>> cmd="echo \"a3\" ${log}"
>>> echo $cmd
>>> $cmd
>>> more ${logfile}
>>>
>>> Here's execution output:
>>>
>>> # ./t1.sh
>>> a2 >> supposed-to-be.log
>>> echo "a3" >> supposed-to-be.log
>>> "a3" >> supposed-to-be.log
>>> a1
>>>
>>> 1. My question is - Which are correct way to specify such redirects to be
>>> overridden?
>>>
>>
>> If you must have a conditional redirect in the above manner (in which the
>> redirect syntax is part of a variable):
>>
>> to_foofile=">> foofile"
>> eval echo \"a1\" $to_foofile
>>
>> The shell will do a first-pass on the arguments, so what "eval" sees as
>> arguments are:
>>
>> echo "a1" >> foofile
>>
>> And thus, eval does what it does best… evaluates the expressions as a set of
>> shell statements.
>>
>> NOTE: The rc script probably assumed bash and was ported from another system
>> where /bin/sh was indeed bash (but in FreeBSD, /bin/sh is not bash and is
>> much more strict in adhering to POSIX standards).
>>
>> However, I can't in all earnest recommend that approach as a method of
>> conditional logging when there are so many better solutions.
>>
>> Here's one of my favorites for quick-and-dirty conditional logging:
>>
>> ===
>>
>> #!/bin/sh
>>
>> if : some condition to enable debugging; then
>> exec 3>>/tmp/log.stdout 4>>/tmp/log.stderr
>> else
>> exec 3>&1 4>&2
>> fi
>>
>> echo "a1" 1>&3 2>&4
>> # "a1" ends up in /tmp/log.stdout
>>
>> ls /nosuchfile 1>&3 2>&4
>> # You get in /tmp/log.stderr: "ls: /nosuchfile: No such file or
>> directory"
>>
>> ===
>>
>
> Yeah… don't do that… the moment I hit send, it dawned on me that the extra
> file-descriptor (however cute), is entire unnecessary…
>
> ===
>
> #!/bin/sh
> if : some condition to enable debugging; then
> exec 1>>/tmp/log.stdout 2>>/tmp/log.stderr
> fi
> echo d1
> # if debugging, goes to /tmp/log.stdout
> # if no debugging, goes to console
> ls /nosuchfile
> # if debugging, an error goes to /tmp/log.stderr
> # if no debugging, error goes to console
>
> ===
>
>
>
>> So rather than having to prefix "eval" to every command *and* escape all the
>> quotes and expansions… the above instead changes from (old) attempting to
>> use a conditional redirect syntax (by way of $logging variable) to
>> (new/above) having every command redirect stdout/stderr but having the
>> destinations of the redirect change based on some pre-condition.
>>
>>
>>
>>> 2. tomcat6.in, rubyrep.in, tclhttpd.in, geoserver.in, and many more rc
>>> scripts from ports are using something like this:
>>>
>>> log_args=">> ${tclhttpd_stdout_log} 2>> ${tclhttpd_stderr_log} "
>>>
>>> and after that use $log_args.
>>>
>>> Are they silently broken, or am I missing something?
>>>
>>
>> I would call that broken if the invocation line at the top of the script is
>> #!/bin/sh (it may not be broken if you instead see something like
>> "#!/usr/bin/env bash").
>>
>>
>>
>>
>>> 3. Should I build up $cmd, and run
>>> eval "$cmd" - would this be nice ro dirty hack?
>>>
>>
>> Nah… just go through and replace "$log_args" with either "1>&3 2>&4" or ">&3
>> 2>&4" (the leading 1 on ">&" in the first option is actually the implied
>> default, so you can omit it and go for the second option if you like;
>> however since you can't say "exec 3>&" and have to say "exec 3>&1", I tend
>> to think the first option is more explicitly-clear in what's going on with
>> the file-descriptors).
>>
>
> Actually… you could potentially fix this with one line of code…
>
> [ "$logging" ] && exec 1>>/tmp/log.stdout 2>>/tmp/log.stderr
>
> And then go remove the "$logging" from the end of each line.
Even better than removing "$logging" (or $log_args) from the end of each line…
Just set it to NULL.
So in the case of your earlier example…
>>> %%APP_SHORTNAME%%_logging="${%%APP_SHORTNAME%%_logging:-">>
>>> ${%%APP_SHORTNAME%%_logdir}/stdout.log 2>>
>>> ${%%APP_SHORTNAME%%_logdir}/stderr.log"}"
I would do the following…
#
# Do the real t
