[request-sponsor] Requesting sponsor for CR#6474270 ("isaexec and magical builds") ...
I can help you with this, but I think we need to solve some additional problems
w/ isaexec as well as the one detailed in this bug report; Jim Carlsen's
comments in the bug report are on target here:
The isaexec issue doesn't seem to ring true for Perl, at least not for
the one we ship.
% truss -fo /tmp/jdc /usr/bin/perl < /dev/null
% grep exec /tmp/jdc
432101: execve("/usr/perl5/5.8.4/bin/perl", 0xFFBFF374, 0xFFBFF37C) argc = 1
%
I don't doubt there are other obscure cases where this feature could cause
trouble, though. To make this fix complete, I think you'd have to hack
at the kernel interface, though. Merely hacking the user space utility
would leave applications that know about the public isaexec(3C) interface
vunerable and strangely unaffected.
Thus, I'm moving this over to the kernel category.
*** (#2 of 2): 2007-11-27 09:40:38 PST james.d.carlson at sun.com
--
This message posted from opensolaris.org
[request-sponsor] Adding status support to dd
James Carlson wrote: > James Carlson writes: >> Frank Van Der Linden writes: >>> Matty wrote: >>>> Howdy, >>>> >>>> Most Linux and BSD distributions ship with a version of dd that >>>> displays the status of a copy operation when a SIGUSR1 signal is >>>> received. >>> Just a correction. I know this is late in the game, and I don't want to >>> prolong the discussion much, since this isn't the right list, but: *BSD >>> uses SIGINFO, which is generated via the tty code when the user presses >>> ^T. Several tools implement a status handler that uses SIGINFO. >> CR 6310532, now celebrating its first birthday. > > Ah, surprise. I filed it even longer ago. ;-} > Sounds like we could implement the Linux behavior wrt SIGUSR1 and then add SIGINFO support trivially once that appeared in the terminal handler... - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
[request-sponsor] Adding status support to dd
Bonnie Corwin wrote: > Hi Bart, > > I assume your comment about helping to get this into shape means you > will sponsor Ryan's work. Can someone file a bug, if there isn't one > already, so I can add this to the table? > > Thanks. > > Bonnie 6543165 dd should display incremental progress ala linux in response to sigusr1 - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
[request-sponsor] Adding status support to dd
Matty wrote:
> On 4/5/07, James Carlson wrote:
>> Darren J Moffat writes:
>> > Matty wrote:
>> > > Howdy,
>> > >
>> > > Most Linux and BSD distributions ship with a version of dd that
>> > > displays the status of a copy operation when a SIGUSR1 signal is
>> > > received. For some reason /usr/bin/dd on Solaris hosts doesn't
>> contain
>> > > this capability, and I would like to add it. After reading through
>> the
>> > > source code for dd.c, it looks like adding this support would be as
>> > > simple as installing a signal handler for SIGUSR1, and having it call
>> > > the function stats. I am attaching code (which I copied from the dd
>> > > that ships with Fedora Core Linux)
>> >
>> > What license is that dd code you copied under ?
>> >
>> > You can't just copy code like that without considering the licenses.
>>
>> Indeed. That's GPLv2 code, which would require OpenSolaris dd to
>> become GPLv2 as well.
>>
>> That can't be done. Either start provably from scratch or use
>> software under a compatible license.
>
> Your absolutely right, and Stephen Hahn was nice enough to point this
> out in an email last night. Since the existing code uses signal to
> register the SIGINT signal handler (I reckon the issues Bart mentioned
> are minimized since it exit()'s after printing the statistics):
>
> if (signal(SIGINT, SIG_IGN) != SIG_IGN)
> {
> (void) signal(SIGINT, term);
> }
>
> Do folks see any issue with using similar code to add a SIGUSR1 signal
> handler?:
>
> if (signal(SIGUSR1, SIG_IGN) != SIG_IGN)
> {
>(void) signal(SIGUSR1, stats);
> }
>
> This would minmize the amount of code that would need to be added to
> get stats functionality, and would address the license issues. If this
> solution isn't acceptable, could I get a sponsor assigned to help me
> work through a community approved solution?
>
> Thanks,
> - Ryan
Note that SA_RESTART must be set; otherwise dd from a pipe or other slow
device will return an error condition. I also like Casper's suggestion
to use sprintf and write to stderr, since sprintf is now
async-signal-safe.
I can help you get this into shape.
- Bart
--
Bart Smaalders Solaris Kernel Performance
barts at cyber.eng.sun.com http://blogs.sun.com/barts
[request-sponsor] Adding status support to dd
Matty wrote: > Howdy, > > Most Linux and BSD distributions ship with a version of dd that > displays the status of a copy operation when a SIGUSR1 signal is > received. For some reason /usr/bin/dd on Solaris hosts doesn't contain > this capability (it has a signal handler for SIGINT which causes stats > to be displayed, but the handler calls exit() after printing the > statistics), and I would like to add it. After reading through the > source code for dd.c, it looks like adding this support would be as > simple as installing a signal handler for SIGUSR1, and having it call > the function stats. I am attaching code (which I derived from the dd > source code that comes with Fedora Core Linux) [1] to add this support > to /usr/bin/dd, and have tested it on my build 54 machine. Would it be > possible to integrate this or something similar to opensolaris > (assuming this doesn't break some rule defined by the SUS or POSIX)? > > Thanks, > - Ryan > -- > UNIX Administrator > http://prefetch.net > > [1] > > /* Create a signal handler for SIGUSR1 so dd can display stats for > active copies.*/ > struct sigaction sa; > memset(&sa, 0, sizeof(sa)); > sa.sa_handler = stats; > sa.sa_flags = SA_RESTART; > sigemptyset(&sa.sa_mask); > sigaction(SIGUSR1, &sa, 0); > ___ > request-sponsor mailing list > request-sponsor at opensolaris.org The code changes are obvious enough. However, there exists a small possibility of deadlock if the process receives a signal as it is encountering errors or exiting, as neither fprintf and gettext are async signal safe. If either routine holds a lock when it is interrupted and then gets called again in the signal handler, things can go badly awry. We don't actually deadlock (although perhaps we should), but output, etc, can get rather garbled. In general, a cleaner way to handle this is to block sigusr1 in the main thread, and create a thread to handle the sigusr1 and sigint synchronously using sigwait(2). If sigint is caught, the thread calls stats() and exits. If sigusr1 is caught, the thread calls stats() and then calls sigwait(2) again. This is prob. overkill in this situation... since the main loop will only do stdio just before exiting, it could set signal handlers to SIG_IGN before doing any IO which should prevent any problems from arising. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
[request-sponsor] Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to /tmp/$LOGNAME/") ...
Darren J Moffat wrote:
> Roland Mainz wrote:
>> Hi!
>>
>>
>>
>> Requesting sponsor for CR# 6488593 ("/etc/profile should set TMPDIR to
>> /tmp/$LOGNAME/") - patch is included in the RFE...
>
> This will I believe need an ARC case since it is a change in default
> behaviour. It also should be done for all shells not just ones
> that read /etc/profile.
>
> Since I do this myself in my own .profile I feel duty bound to stand up
> to the plate and by your sponsor for this. So sign me up for putback
> sponsor and I'll be ARC case submitter too.
>
Good idea (I use this myself :-)). Should the directory be created
700 by default?
- Bart
--
Bart Smaalders Solaris Kernel Performance
barts at cyber.eng.sun.com http://blogs.sun.com/barts
