From: guijianfeng@cn.fujitsu.com (Gui Jianfeng)
Subject: [ltt-dev] [PATCH] LTTng: Make mark-control work in debugfs
Date: Mon, 16 Feb 2009 13:16:19 +0800 [thread overview]
Message-ID: <4998F6A3.4050001@cn.fujitsu.com> (raw)
In-Reply-To: <20090216043703.GA27302@Krystal>
Mathieu Desnoyers wrote:
> * Gui Jianfeng (guijianfeng at cn.fujitsu.com) wrote:
>> KOSAKI Motohiro wrote:
>>>> Hi Mathieu,
>>>>
>>>> I guess it's not easy to implement the *mkdir* for marker control.
>>>> But I have an alternative solution that we can add a control file
>>>> *new_channel* at the same level of channel directories, and add a
>>>> control file *new_marker* in each channel directory.
>>>> Making use of the following, we can create a marker even if it
>>>> doesn't exist by now.
>>>>
>>>> cd /mnt/ltt/markers
>>>> echo "channel_name" > new_channel
>>>> echo "marker_name" > channel_name/new_marker
>>> No.
>>> good user interface is important than easy implementation.
>>>
>>> this UI is really ugly.
>> Hi Kosaki-san,
>>
>> Thank you for your kind comments.
>> I say *not easy* becasue debugfs itself doesn't support *mkdir* completely.
>> If we are going to implement mkdir in marker control, we have to modify debugfs
>> itself. IMHO, it's not reasonable and i guess most of the debugfs subsystems don't
>> like to see this change.
>> On the other hand, it's very natual to use a control file to do something in debugfs.
>> So, I choose this solution. I hope that what I say will clarify the situation.:)
>> Mathieu, What do you say?
>>
>
> Hi Gui,
>
> I would recommend adding mkdir support in our own directories. That
> means we have to override debugfs use of "simple" libfs basic
> operations. We want to use the same operations, but also define a mkdir
> callback. See
>
> fs/debugfs/inode.c:
> debugfs_get_inode :
> it sets inode->i_op = &simple_dir_inode_operations;
>
> We will need to override this with our own. See
> fs/libfs.c: simple_dir_inode_operations
>
Ah, I see now, thanks for the suggestion,
> I fully agree with Kosaki : the quality of the user interface is what
> matters and is much more important than implementation difficulty.
Me too :)
>
> Thanks,
>
> Mathieu
>
>>>
>>>
>>>
>>>
>>>
>> --
>> Regards
>> Gui Jianfeng
>>
>>
>> _______________________________________________
>> ltt-dev mailing list
>> ltt-dev at lists.casi.polymtl.ca
>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>>
>
--
Regards
Gui Jianfeng
prev parent reply other threads:[~2009-02-16 5:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-04 1:46 Gui Jianfeng
2009-02-04 6:20 ` Mathieu Desnoyers
2009-02-04 6:30 ` Mathieu Desnoyers
2009-02-04 6:44 ` Gui Jianfeng
2009-02-04 7:12 ` Mathieu Desnoyers
2009-02-05 1:20 ` Gui Jianfeng
2009-02-11 5:32 ` Mathieu Desnoyers
2009-02-11 8:43 ` Mathieu Desnoyers
2009-02-11 9:27 ` Gui Jianfeng
2009-02-11 16:56 ` Mathieu Desnoyers
2009-02-13 6:24 ` Gui Jianfeng
2009-02-13 6:54 ` Mathieu Desnoyers
2009-02-16 2:43 ` Gui Jianfeng
2009-02-16 3:16 ` KOSAKI Motohiro
2009-02-16 3:48 ` Gui Jianfeng
2009-02-16 4:37 ` Mathieu Desnoyers
2009-02-16 5:16 ` Gui Jianfeng [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4998F6A3.4050001@cn.fujitsu.com \
--to=guijianfeng@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox