Re: linux-next: proc tree build failure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[Cyrill Gorcunov - Fri, Jan 23, 2009 at 10:41:09PM +0300]
| [Cyrill Gorcunov - Fri, Jan 23, 2009 at 10:26:07PM +0300]
| | [Alexey Dobriyan - Fri, Jan 23, 2009 at 09:48:37PM +0300]
| | ...
| | | > Hi Stephen,
| | | > 
| | | > thanks for catching this. Until I miss something --
| | | > s_fs_info for /proc is struct pid_namespace* right?
| | | > So maybe_get_net will convert it to net*, which is
| | | > not right I guess. On the other hand -- and PDE, and
| | | > PDE_NET is defined in proc_fs.h regardless if CONIG_PROC_FS
| | | > is turned on/off. Confused...
| | | > 
| | | > (to be fair -- this maybe_get_net(PDE_NET(PDE(inode))) is
| | | >  taken from proc_net.c:get_proc_net, but to eliminate #ifdef
| | | >  I reimplemented it, which is not good too -- maybe I've been
| | | >  to put get_proc_net into some header, Eric?)
| | | 
| | | PDE_NET here is bogus. you should use seq_open_net/seq_release_net.
| | | See how other code does this, plenty of examples.
| | | 
| | 
| | The question is not in examples, I saw that code.
| | There is some problem with seq_open_net/seq_release_net --
| | I don't need additional private data for sequential files,
| | all I need is just a pointer (ie -- seq_file.private) which
| | is already allocated for seq_file structure itself. So
| | Alexey, why should I use seq_open_net then and ask for
| | additional memory which I don't need? (side note:
| | actually get_net/put_net is really needed here indeed).
| | 
| | 		- Cyrill -
| 
| On the other hand - Alexey could we 'teach' seq_open_net/seq_release_net
| to handle 0 private size? So then I could be able to set
| seq_file.private to NULL
| and call seq_release_net without problems?
| 
| 		- Cyrill -

But if the only right way to play with this is to use seq_open/release_net
then I will change the PPPoX code. Alexey?

		- Cyrill -
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux