deprecated TIOCSPGRP and TIOCGPGRP ioctl command

[Warner Losh]

I tend to agree: aren't there more pressing problems in the project that will solve actual problems rather than create a lot of work to save a tiny number of bytes in the object code.

Warner

On Nov 9, 2011, at 8:18 PM, Alfred Perlstein wrote:

> This just reeks of gratuitous breakage.  Sure it's 
> marked depricated, but there's little reason to break a ton
> of applications just to remove 11 lines of code.
> 
> Maybe we can put it under an ifndef IVORY_TOWER.
> 
> -Alfred
> 
> * Garrett Cooper <yanegomi at gmail.com> [111109 18:22] wrote:
>> On Nov 9, 2011, at 4:49 PM, Peter Wemm wrote:
>> 
>>> On Wed, Nov 9, 2011 at 3:39 PM, Giovanni Trematerra <gianni at freebsd.org> wrote:
>>>> Are they deprecated enough to be removed, now?
>>>> FYI FIFO doesn't support them.
>>>> 
>>>> --
>>>> Gianni
>>>> 
>>>> =================================
>>>> --- sys/kern/sys_pipe.c (revision 227233)
>>>> +++ sys/kern/sys_pipe.c (working copy)
>>>> @@ -1304,17 +1304,6 @@ pipe_ioctl(fp, cmd, data, active_cred, td)
>>>>       *(int *)data = fgetown(&mpipe->pipe_sigio);
>>>>       break;
>>>> 
>>>> -   /* This is deprecated, FIOSETOWN should be used instead. */
>>>> -   case TIOCSPGRP:
>>>> -       PIPE_UNLOCK(mpipe);
>>>> -       error = fsetown(-(*(int *)data), &mpipe->pipe_sigio);
>>>> -       goto out_unlocked;
>>>> -
>>>> -   /* This is deprecated, FIOGETOWN should be used instead. */
>>>> -   case TIOCGPGRP:
>>>> -       *(int *)data = -fgetown(&mpipe->pipe_sigio);
>>>> -       break;
>>>> -
>>>>   default:
>>>>       error = ENOTTY;
>>> 
>>> Be very very careful with this.  It's part of the classic BSD job
>>> control API.  It would be wise to survey whether any ports shells use
>>> this.
>>> 
>>> You might also want to consider things like this in libc:
>>> int
>>> tcsetpgrp(int fd, pid_t pgrp)
>>> {
>>>       int s;
>>> 
>>>       s = pgrp;
>>>       return (_ioctl(fd, TIOCSPGRP, &s));
>>> }
>>> Our own libc code uses this, albeit on an API intended to be used on a tty.
>>> 
>>> The shell I'd be most concerned about is csh/tcsh in our tree. It has
>>> quite an #ifdef legacy layer and I couldn't convince myself it wasn't
>>> using this indirectly (or the tc* functions) on pipes.
>>> 
>>> It might also be an idea to see if the linux compat layer can be
>>> switched over to using the newer API.
>> 
>> Move to a compat library perhaps?
>> -Garrett_______________________________________________
>> freebsd-arch at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
> 
> -- 
> - Alfred Perlstein
> .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10
> .- FreeBSD committer
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
> 
>