内核列表中补丁标题的 RFC 是什么意思？

[sniper]

rt
_______________________________________________
Linux 内核开发中文邮件列表
Linux-...@zh-kernel.org
http://zh-kernel.org/mailman/listinfo/linux-kernel
Linux 内核开发中文社区： http://zh-kernel.org

[Deng Xiaojun]

模仿ietf的rfc(request for comment)?

2008/11/29 sniper <s3c...@gmail.com>:

[Zhang Le]

On 19:52 Sat 29 Nov , Deng Xiaojun wrote:
> 模仿ietf的rfc(request for comment)?

正是
征求意见的意思

Zhang, Le

[Thomas X. Iverson]

2008/11/29 Zhang Le <r0b...@gentoo.org>:

学习了

--
Keep It Simple Stupid

http://blog.ghostunix.org

ghosTM55

[yi.y.yang]

Request For Comments.

sniper 写道:

[Yang Hongyang]

Zhang Le wrote:
> On 19:52 Sat 29 Nov , Deng Xiaojun wrote:
>> 模仿ietf的rfc(request for comment)?
>
> 正是
> 征求意见的意思
>
> Zhang, Le
> _______________________________________________

应该是针对内核实现与RFC说明不一致的地方发的patch吧。

[Wang Jian]

Yang Hongyang 写道:

> Zhang Le wrote:
>> On 19:52 Sat 29 Nov , Deng Xiaojun wrote:
>>> 模仿ietf的rfc(request for comment)?
>> 正是
>> 征求意见的意思
>>
>> Zhang, Le
>> _______________________________________________
>
> 应该是针对内核实现与RFC说明不一致的地方发的patch吧。

此 RFC 和 彼 RFC 除了字面意思相同外，毫无关系

当对内核进行某种改进或者实现新的接口，而不确定这是否合适时，可以 RFC 请其他人一起
评估。

[Yang Hongyang]

Wang Jian wrote:
> Yang Hongyang 写道:
>> Zhang Le wrote:
>>> On 19:52 Sat 29 Nov , Deng Xiaojun wrote:
>>>> 模仿ietf的rfc(request for comment)?
>>> 正是
>>> 征求意见的意思
>>>
>>> Zhang, Le
>>> _______________________________________________
>>
>> 应该是针对内核实现与RFC说明不一致的地方发的patch吧。
>
> 此 RFC 和 彼 RFC 除了字面意思相同外，毫无关系
>
> 当对内核进行某种改进或者实现新的接口，而不确定这是否合适时，可以 RFC 请
> 其他人一起
> 评估。
>
>

sniper问的是补丁标题的 RFC 是什么意思，我觉得是说明该补丁是针对内核实现与RFC说明
不一致的地方或者针对RFC中有说明而内核中还没有实现的部分，也就是你所说的改进或者
实现新的接口。当然，补丁发到了内核列表中，肯定是为了让大家讨论该补丁是否可以应用。

单纯的讨论RFC的邮件也有，但不是patch.

[Li Zefan]

Yang Hongyang 写道:

> Wang Jian wrote:
>> Yang Hongyang 写道:
>>> Zhang Le wrote:
>>>> On 19:52 Sat 29 Nov , Deng Xiaojun wrote:
>>>>> 模仿ietf的rfc(request for comment)?
>>>> 正是
>>>> 征求意见的意思
>>>>
>>>> Zhang, Le
>>>> _______________________________________________
>>> 应该是针对内核实现与RFC说明不一致的地方发的patch吧。
>> 此 RFC 和 彼 RFC 除了字面意思相同外，毫无关系
>>
>> 当对内核进行某种改进或者实现新的接口，而不确定这是否合适时，可以 RFC 请
>> 其他人一起
>> 评估。
>>
>>
>
> sniper问的是补丁标题的 RFC 是什么意思，我觉得是说明该补丁是针对内核实现与RFC说明
> 不一致的地方或者针对RFC中有说明而内核中还没有实现的部分，也就是你所说的改进或者
> 实现新的接口。当然，补丁发到了内核列表中，肯定是为了让大家讨论该补丁是否可以应用。
>
> 单纯的讨论RFC的邮件也有，但不是patch.

貌似是你想的太复杂了。。内核邮件的标题带有RFC，就是单纯的说明patch(或没有patch而是
一个idea)需要讨论，作者并不是很确定patch是否合适。

[Yang Hongyang]

Li Zefan wrote:
> Yang Hongyang 写道:
>> Wang Jian wrote:
>>> Yang Hongyang 写道:
>>>> Zhang Le wrote:
>>>>> On 19:52 Sat 29 Nov , Deng Xiaojun wrote:
>>>>>> 模仿ietf的rfc(request for comment)?
>>>>> 正是
>>>>> 征求意见的意思
>>>>>
>>>>> Zhang, Le
>>>>> _______________________________________________
>>>> 应该是针对内核实现与RFC说明不一致的地方发的patch吧。
>>> 此 RFC 和 彼 RFC 除了字面意思相同外，毫无关系
>>>
>>> 当对内核进行某种改进或者实现新的接口，而不确定这是否合适时，可以 RFC 请
>>> 其他人一起
>>> 评估。
>>>
>>>
>> sniper问的是补丁标题的 RFC 是什么意思，我觉得是说明该补丁是针对内核实现与RFC说明
>> 不一致的地方或者针对RFC中有说明而内核中还没有实现的部分，也就是你所说的改进或者
>> 实现新的接口。当然，补丁发到了内核列表中，肯定是为了让大家讨论该补丁是否可以应用。
>>
>> 单纯的讨论RFC的邮件也有，但不是patch.
>
> 貌似是你想的太复杂了。。内核邮件的标题带有RFC，就是单纯的说明patch(或没有patch而是
> 一个idea)需要讨论，作者并不是很确定patch是否合适。
>
>

貌似你想得太简单了。。。内核邮件的标题不管是带有RFC还是不带有RFC，还是带有其它的什么，
一般都是单纯的说明patch(或没有patch而是一个idea)需要讨论，作者并不是很确定patch是否合适，
或者作者确定patch合适，发出来让大家讨论确认，获得大家的认可。。。从而得到appliy。。。

[Bin Meng]

邮件列表里的RFC肯定不是你说的针对RFC的patch，就是让大家注解的request for comments.

2008/12/1 Yang Hongyang <yan...@cn.fujitsu.com>:

[Jike Song]

2008/12/1 Bin Meng <bmen...@gmail.com>:
> 邮件列表里的RFC肯定不是你说的针对RFC的patch，就是让大家注解的request for comments.

对啊，comments的意思就是请大家review， 作者不确定这个patch/idea是否有用/有意义，或者不确定这个实现是否有问题，所以题目上加一个RFC。

[Yang Hongyang]

Bin Meng wrote:
> 邮件列表里的RFC肯定不是你说的针对RFC的patch，就是让大家注解的request for comments.

sorry, i was wrong

[Bin Meng]

Jike，貌似你理解错我的意思了 or 回错邮件了 :-)

2008/12/1 Jike Song <albc...@gmail.com>:

[Yang Hongyang]

Jike Song wrote:
> 2008/12/1 Bin Meng <bmen...@gmail.com>:
>> 邮件列表里的RFC肯定不是你说的针对RFC的patch，就是让大家注解的request for comments.
>
> 对啊，comments的意思就是请大家review， 作者不确定这个patch/idea是否有用/有意义，或者不确定这个实现是否有问题，所以题目上加一个RFC。

是的，我又搜索了一下邮件列表，发现此RFC确实非我想的RFC，有点想当然了。。。

[Wang Jian]

Yang Hongyang 写道:

带 RFC 标题的，其首要目的是寻求对“策略”的认同或者反对的意见。当然随后也会讨论到具体实现
上的问题，但这不是 "RFC" 首要解决的。

举个 RFC 标题的例子(我随便 google 的一个)
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-09/4195.html

在这个 Simple FIFO 实现的讨论中，一开始，作者提出 FIFO 的实现是可以简化的，这是个“策略”
上的想法。很明显，回复的人认同了他的“策略”，但对“实现”有疑问。随后的讨论都是基于具体
的“实现”了，代码上的问题一一被解决。在最后，polished patch 被发到邮件组。

比如我发过的一个关于 8bit data line 的 CF 卡 patch，我对 ATA 子系统不熟悉，不能确定合适的
位置，所以需要别人给我一些意见。Tejun Heo 的意见是应该放到 ata core 中，而 Alan Cox 的意见
是这个扩展只适用于 cf 卡，不适合放到 ata core 中。这就是关于“策略”的讨论。

也有很多涉及到“策略”的 patch 被直接发到邮件组，原因可能是作者很有信心，也可能是作者并
没有意识到这中间有策略的问题。

有一部分不涉及到“策略”的邮件也有 RFC 在标题里面，可能是因为作者比较谨慎。

[Yang Hongyang]

Thank you for your explain.:)

[Li Yang]

>
> 带 RFC 标题的，其首要目的是寻求对“策略”的认同或者反对的意见。当然随后也会讨论到具体实现
> 上的问题，但这不是 "RFC" 首要解决的。
>
> 举个 RFC 标题的例子(我随便 google 的一个)
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-09/4195.html
>
> 在这个 Simple FIFO 实现的讨论中，一开始，作者提出 FIFO 的实现是可以简化的，这是个“策略”
> 上的想法。很明显，回复的人认同了他的“策略”，但对“实现”有疑问。随后的讨论都是基于具体
> 的“实现”了，代码上的问题一一被解决。在最后，polished patch 被发到邮件组。
>
> 比如我发过的一个关于 8bit data line 的 CF 卡 patch，我对 ATA 子系统不熟悉，不能确定合适的
> 位置，所以需要别人给我一些意见。Tejun Heo 的意见是应该放到 ata core 中，而 Alan Cox 的意见
> 是这个扩展只适用于 cf 卡，不适合放到 ata core 中。这就是关于“策略”的讨论。
>
> 也有很多涉及到“策略”的 patch 被直接发到邮件组，原因可能是作者很有信心，也可能是作者并
> 没有意识到这中间有策略的问题。
>
> 有一部分不涉及到“策略”的邮件也有 RFC 在标题里面，可能是因为作者比较谨慎。

判断是否需要加[RFC]的最主要问题是自己的态度，对自己的patch或者想法是否很有信心。 不加RFC的patch至少应该是自己觉得很正确很成熟的，期望维护者merge的。当然自己认为正确的patch，别人不见得认可，所以往往还是会有很多提意见和修改的过程。加了RFC就好比是有了免责条款“我也不清楚这么做是否正确，所以板砖轻点拍”。讨论策略的邮件RFC比较多，只不过是因为策略问题比较敏感通常异议会比较多，所以更需要谨慎。拿不准的东西，我建议最好都是要加上RFC的。

- Leo

[wanglh]

有人做过数据压缩相关的东西吗？
现在想在linux kernel层实现一个数据压缩的功能。
但是似乎没有提供这方面的函数。

找到了一个zlib，是用户层的，有很多系统调用，还需要移植到内核。
谢谢！

[Zhaolei]

参见内核中的linux/lib/zlib*

[Liu Hui]

这是kernel自带的，在lib目录下：
#
# compression support is select'ed if needed
#
config ZLIB_INFLATE
tristate

config ZLIB_DEFLATE
tristate

config LZO_COMPRESS
tristate

config LZO_DECOMPRESS
tristate

2008/12/1 wanglh <wan...@nec-as.nec.com.cn>:

--
Thanks & Best Regards
Liu Hui
--