Re: /proc/#/ctl removal

2017-08-28 Thread Christos Zoulas 
In article ,
Johnny Billquist   wrote:
>On 2017-08-27 14:09, D'Arcy Cain wrote:
>> On 08/27/2017 03:59 AM, Christos Zoulas wrote:
>>> LGTM, perhaps leave a comment /* old P_FSTRACE    0x0001 */
>>> instead of completely removing the constants for now as a reminder.
>> 
>> Isn't that sort of duplicating what CVS does?
>
>I would say no. CVS allows you to go back in history, see what changed, 
>see how things were before, and so on.
>Documenting something in the code is useful for people who are writing 
>code. It would be impossible to always go back and check the full 
>history of every file when you are doing work. If there is something 
>that is useful for the future to be aware of, it needs to be documented 
>in the code, including if it is something of related to history.
>
>If it is totally irrelevant for future code writing, then there is no 
>need to keep any comment in the code, but if, for example, some constant 
>of value in a larger range historically was used for something, this is 
>important to keep around, even if it is no longer used, as it should 
>maybe be left unused/undefined, and if you need some new value, you 
>should grab a different one. If you get what I mean.

Bottom line:

It is a lot of extra work to riffle though cvs versions to find if the
unused bit was ever allocated, what was it used for, and when was it
deleted when you want to use one of the unused bits for something new.
The comment helps, but it is not the end of the world if it is not
there.

christos

Re: /proc/#/ctl removal

2017-08-27 Thread Johnny Billquist 

On 2017-08-27 14:09, D'Arcy Cain wrote:

On 08/27/2017 03:59 AM, Christos Zoulas wrote:

LGTM, perhaps leave a comment /* old P_FSTRACE    0x0001 */
instead of completely removing the constants for now as a reminder.


Isn't that sort of duplicating what CVS does?


I would say no. CVS allows you to go back in history, see what changed, 
see how things were before, and so on.
Documenting something in the code is useful for people who are writing 
code. It would be impossible to always go back and check the full 
history of every file when you are doing work. If there is something 
that is useful for the future to be aware of, it needs to be documented 
in the code, including if it is something of related to history.


If it is totally irrelevant for future code writing, then there is no 
need to keep any comment in the code, but if, for example, some constant 
of value in a larger range historically was used for something, this is 
important to keep around, even if it is no longer used, as it should 
maybe be left unused/undefined, and if you need some new value, you 
should grab a different one. If you get what I mean.


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: /proc/#/ctl removal

2017-08-27 Thread Johnny Billquist 

On 2017-08-27 23:20, Kamil Rytarowski wrote:

On 27.08.2017 16:07, Johnny Billquist wrote:

On 2017-08-27 14:09, D'Arcy Cain wrote:

On 08/27/2017 03:59 AM, Christos Zoulas wrote:

LGTM, perhaps leave a comment /* old P_FSTRACE0x0001 */
instead of completely removing the constants for now as a reminder.


Isn't that sort of duplicating what CVS does?


I would say no. CVS allows you to go back in history, see what changed,
see how things were before, and so on.
Documenting something in the code is useful for people who are writing
code. It would be impossible to always go back and check the full
history of every file when you are doing work. If there is something
that is useful for the future to be aware of, it needs to be documented
in the code, including if it is something of related to history.

If it is totally irrelevant for future code writing, then there is no
need to keep any comment in the code, but if, for example, some constant
of value in a larger range historically was used for something, this is
important to keep around, even if it is no longer used, as it should
maybe be left unused/undefined, and if you need some new value, you
should grab a different one. If you get what I mean.

   Johnny



I use git mirror for data mining.


[...]
You can do similar with any revision control system. But data mining is 
a different thing than writing code and knowing about details from past 
history. Which was my point.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: /proc/#/ctl removal

2017-08-27 Thread Kamil Rytarowski 
On 27.08.2017 16:07, Johnny Billquist wrote:
> On 2017-08-27 14:09, D'Arcy Cain wrote:
>> On 08/27/2017 03:59 AM, Christos Zoulas wrote:
>>> LGTM, perhaps leave a comment /* old P_FSTRACE0x0001 */
>>> instead of completely removing the constants for now as a reminder.
>>
>> Isn't that sort of duplicating what CVS does?
> 
> I would say no. CVS allows you to go back in history, see what changed,
> see how things were before, and so on.
> Documenting something in the code is useful for people who are writing
> code. It would be impossible to always go back and check the full
> history of every file when you are doing work. If there is something
> that is useful for the future to be aware of, it needs to be documented
> in the code, including if it is something of related to history.
> 
> If it is totally irrelevant for future code writing, then there is no
> need to keep any comment in the code, but if, for example, some constant
> of value in a larger range historically was used for something, this is
> important to keep around, even if it is no longer used, as it should
> maybe be left unused/undefined, and if you need some new value, you
> should grab a different one. If you get what I mean.
> 
>   Johnny
> 

I use git mirror for data mining.

Mirror: https://github.com/NetBSD/src/

Useful commands:
git log -p -- file-or-directory
git log --grep "message"

Some of operations are quicker through GitHub, as it has indexed the
repository. GitHub can be also used to scan open-source software
available on this hosting site for code or phrase in a commit message.



signature.asc
Description: OpenPGP digital signature

Re: /proc/#/ctl removal

2017-08-27 Thread Christos Zoulas 
On Aug 27,  8:09am, da...@netbsd.org (D'Arcy Cain) wrote:
-- Subject: Re: /proc/#/ctl removal

| Isn't that sort of duplicating what CVS does?

Yes, but:
1. it has been existing practice
2. it is not easy to find the missing value from cvs
3. when someone wants to add a new value, it is best to understand that
   this is now being re-used (or it has been used recently).

Anyway, does not matter too much. And since Kamil does not want to do it,
it will not get done :-)

christos

Re: /proc/#/ctl removal

2017-08-27 Thread D'Arcy Cain 

On 08/27/2017 03:59 AM, Christos Zoulas wrote:

LGTM, perhaps leave a comment /* old P_FSTRACE  0x0001 */
instead of completely removing the constants for now as a reminder.


Isn't that sort of duplicating what CVS does?

--
D'Arcy J.M. Cain 
http://www.NetBSD.org/ IM:da...@vex.net

Re: /proc/#/ctl removal

2017-08-27 Thread Kamil Rytarowski 
On 27.08.2017 09:59, Christos Zoulas wrote:
> On Aug 26,  4:04pm, n...@gmx.com (Kamil Rytarowski) wrote:
> -- Subject: Re: /proc/#/ctl removal
> 
> | I will do it.
> | 
> | Draft patch: http://netbsd.org/~kamil/patch-00036-procfs_ctl.txt
> | 
> | I plan to commit it on Monday.
> 
> LGTM, perhaps leave a comment /* old P_FSTRACE0x0001 */
> instead of completely removing the constants for now as a reminder.
> 
> christos
> 

These values are already documented as waiting for removal. There were
no users of it in userland (nor in 3rd party software). I will do
something else.. I will document the history of mount_procfs(8) and add
include /proc/#/auxv.



signature.asc
Description: OpenPGP digital signature

Re: /proc/#/ctl removal

2017-08-27 Thread Christos Zoulas 
On Aug 26,  4:04pm, n...@gmx.com (Kamil Rytarowski) wrote:
-- Subject: Re: /proc/#/ctl removal

| I will do it.
| 
| Draft patch: http://netbsd.org/~kamil/patch-00036-procfs_ctl.txt
| 
| I plan to commit it on Monday.

LGTM, perhaps leave a comment /* old P_FSTRACE  0x0001 */
instead of completely removing the constants for now as a reminder.

christos

Re: /proc/#/ctl removal

2017-08-26 Thread Kamil Rytarowski 
On 21.08.2017 12:13, Christos Zoulas wrote:
> In article ,
> Kamil Rytarowski   wrote:
>> -=-=-=-=-=-
>> -=-=-=-=-=-
>>
>> I plan to remove the filesystem process tracing capability through
>> /proc/#/ctl. This is a legacy interface from 4.4BSD, and it was
>> introduced to overcome shortcomings of ptrace(2) at that time, which are
>> no longer relevant (performance). Today /proc/#/ctl offers a narrow
>> subset of ptrace(2) commands and is not applicable for modern
>> applications use beyond simplistic tracing scenarios.
>>
>> This removal will simplify kernel internals. Users will still be able to
>> use all the other /proc files.
>>
>> Presumably there are no known users of this interface and this is why I
>> plan to remove it without compat options.
>>
>> This change won't affect other procfs files neither Linux compat
>> features within mount_procfs(8). /proc/#/ctl isn't available on Linux.
> 
> Nothing to my knowledge uses is. Don't forget to cleanup the
> kernel ptrace code too (PSL_FSTRACE).
> 
> christos
> 

I will do it.

Draft patch: http://netbsd.org/~kamil/patch-00036-procfs_ctl.txt

I plan to commit it on Monday.



signature.asc
Description: OpenPGP digital signature

Re: /proc/#/ctl removal

2017-08-21 Thread David Holland 
On Sun, Aug 20, 2017 at 06:16:54PM +0200, Kamil Rytarowski wrote:
 > I plan to remove the filesystem process tracing capability through
 > /proc/#/ctl. This is a legacy interface from 4.4BSD, and it was
 > introduced to overcome shortcomings of ptrace(2) at that time, which are
 > no longer relevant (performance). Today /proc/#/ctl offers a narrow
 > subset of ptrace(2) commands and is not applicable for modern
 > applications use beyond simplistic tracing scenarios.

Yes please :-)

-- 
David A. Holland
dholl...@netbsd.org

Re: /proc/#/ctl removal

2017-08-21 Thread Christos Zoulas 
In article ,
Kamil Rytarowski   wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>I plan to remove the filesystem process tracing capability through
>/proc/#/ctl. This is a legacy interface from 4.4BSD, and it was
>introduced to overcome shortcomings of ptrace(2) at that time, which are
>no longer relevant (performance). Today /proc/#/ctl offers a narrow
>subset of ptrace(2) commands and is not applicable for modern
>applications use beyond simplistic tracing scenarios.
>
>This removal will simplify kernel internals. Users will still be able to
>use all the other /proc files.
>
>Presumably there are no known users of this interface and this is why I
>plan to remove it without compat options.
>
>This change won't affect other procfs files neither Linux compat
>features within mount_procfs(8). /proc/#/ctl isn't available on Linux.

Nothing to my knowledge uses is. Don't forget to cleanup the
kernel ptrace code too (PSL_FSTRACE).

christos