* [Ocfs2-devel] [RFC] [PATCH] OCFS2 @ 2005-05-18 22:33 ` Mark Fasheh 0 siblings, 0 replies; 42+ messages in thread From: Mark Fasheh @ 2005-05-18 17:33 UTC (permalink / raw) To: linux-kernel, linux-fsdevel, ocfs2-devel Cc: torvalds, akpm, wim.coekaerts, lmb Hello, This is OCFS2, a shared disk cluster file system which we hope will be included in the kernel. We think OCFS2 has many qualities which make it particularly interesting as a cluster file system: -We've tried very hard to avoid the abstraction layers which tend to plague other cluster file systems. Wherever possible, OCFS2 sits directly atop the VFS. Journaling is done via JBD, including node recovery. -Though OCFS2 is an extent based file system, much of the disk layout design has been taken from Ext3. As mentioned before, journal formats are JBD. Though OCFS2 does not yet support htree, directory data looks nearly identical to that of Ext3, with the exception that OCFS2 inode numbers are 64 bits wide. Data and meta data are allocated from dynamically growable "chain allocators" whose chain items look very similar to block groups. -OCFS2 has a strong data locking model, which includes a shared mmap implementation (shared writeable mappings are not yet supported) and full AIO support. -OCFS2 has a very low overhead direct I/O path. Within the file system, the cluster stack below us has been abstracted out as much as possible: -Heartbeat events are delivered to us via a simple callback mechanism. -File system network communication has only minimal knowledge of node information. -File system cluster locking, including lock caching, is handled through a "dlm glue" layer which abstracts away the actual dlm implementation beneath (though it assumes a VMS-like API with a minimal set of features). Included in OCFS2 is a small cluster stack. It should be noted that we do *not* propose this as a generic cluster stack. While we hope the cluster stack can be useful to other projects it was certainly implemented with only the requirements of a cluster file system in mind. Looking towards the future, we would like to either extend this stack to be more generic or plug in a more generic stack - assuming it gives us similar ease of use and performance and has undergone the appropriate community discussion. For now the cluster stack and dlm components have been placed in their respective directories within the "ocfs2" subdirectory. A major goal in the design of OCFS2 was to make configuration of the entire stack as painless as possible. There is only one configuration file required which describes all nodes in an OCFS2 cluster (/etc/ocfs2/cluster.conf). The cluster.conf file is the same for all nodes so that it can be easily re-copied when changed. Anyone wanting to use OCFS2 should download the tool chain from http://oss.oracle.com/projects/ocfs2-tools/source.html The current OCFS2-tools package includes a full set of standard file system utilities (mkfs.ocfs2, fsck.ocfs2, mount.ocfs2, tunefs.ocfs2, debugfs.ocfs). Pulling down the latest subversion tree is usually best. Setup is quite simple, after software installation, either hand create a configuration or use the "ocfs2console" program to generate one for you. Currently the code should be considered beta quality. The OCFS2 team is deep in a cycle of bug fixing and performance evaluation. As a proof of concept, we've been able to bring up a 12 node shared root cluster. Already, performance on the file system looks promising. A parallel kernel build (make -j4 bzImage on each node within their own trees) compares well with ext3: Ext3 OCFS2 node1 13m4s 13m16s node2 10m27s 10m38s In case there is any concern about code size, a quick comparison shows the file system and cluster stacks combined size to be not significantly larger than reiserfs and 1/3 the size of xfs. For people using git, these changes can be pulled from: http://oss.oracle.com/git/ocfs2.git/ A full patch can be downloaded from: http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/complete/ocfs2-configfs-all.patch Broken out versions of the patches can be found at: http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/ A short description of each patch follows. The same descriptions can be found at the top of each patch file. http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/01_configfs.patch Configfs, a file system for userspace-driven kernel object configuration. The OCFS2 stack makes extensive use of this for propagation of cluster configuration information into kernel. http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/02_mlog.patch Very simple printk wrapper which adds the ability to enable various sets of debug messages at run-time. http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/03_nm.patch A simple node information service, filled and updated from userspace. The rest of the stack queries this service for simple node information. http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/04_heartbeat.patch Disk based heartbeat. Configured and started from userspace, the kernel component handles I/O submission and event generation via callback mechanism. http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/05_messaging.patch Node messaging via tcp. Used by the dlm and the file system for point to point communication between nodes. http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/06_dlm.patch A distributed lock manager built with the cluster file system use case in mind. The OCFS2 dlm exposes a VMS style API, though things have been simplified internally. The only lock levels implemented currently are NLMODE, PRMODE and EXMODE. http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/07_dlmfs.patch dlmfs: A minimal dlm userspace interface implemented via a virtual file system. Most of the OCFS2 tools make use of this to take cluster locks when doing operations on the file system. http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/08_ocfs2.patch The OCFS2 file system module. http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/09_build.patch Link the code into the kernel build system. OCFS2 is marked as experimental and we only enable builds on x86, x86-64 and ia64 - endianness consistency is a work in progress. When built, the stack will result in 5 modules: configfs.ko, ocfs2_nodemanager.ko, ocfs2_dlm.ko, ocfs2.ko and ocfs2_dlmfs.ko -- Mark Fasheh Senior Software Developer, Oracle mark.fasheh@oracle.com ^ permalink raw reply [flat|nested] 42+ messages in thread
* [RFC] [PATCH] OCFS2 @ 2005-05-18 22:33 ` Mark Fasheh 0 siblings, 0 replies; 42+ messages in thread From: Mark Fasheh @ 2005-05-18 22:33 UTC (permalink / raw) To: linux-kernel, linux-fsdevel, ocfs2-devel Cc: torvalds, akpm, wim.coekaerts, lmb Hello, This is OCFS2, a shared disk cluster file system which we hope will be included in the kernel. We think OCFS2 has many qualities which make it particularly interesting as a cluster file system: -We've tried very hard to avoid the abstraction layers which tend to plague other cluster file systems. Wherever possible, OCFS2 sits directly atop the VFS. Journaling is done via JBD, including node recovery. -Though OCFS2 is an extent based file system, much of the disk layout design has been taken from Ext3. As mentioned before, journal formats are JBD. Though OCFS2 does not yet support htree, directory data looks nearly identical to that of Ext3, with the exception that OCFS2 inode numbers are 64 bits wide. Data and meta data are allocated from dynamically growable "chain allocators" whose chain items look very similar to block groups. -OCFS2 has a strong data locking model, which includes a shared mmap implementation (shared writeable mappings are not yet supported) and full AIO support. -OCFS2 has a very low overhead direct I/O path. Within the file system, the cluster stack below us has been abstracted out as much as possible: -Heartbeat events are delivered to us via a simple callback mechanism. -File system network communication has only minimal knowledge of node information. -File system cluster locking, including lock caching, is handled through a "dlm glue" layer which abstracts away the actual dlm implementation beneath (though it assumes a VMS-like API with a minimal set of features). Included in OCFS2 is a small cluster stack. It should be noted that we do *not* propose this as a generic cluster stack. While we hope the cluster stack can be useful to other projects it was certainly implemented with only the requirements of a cluster file system in mind. Looking towards the future, we would like to either extend this stack to be more generic or plug in a more generic stack - assuming it gives us similar ease of use and performance and has undergone the appropriate community discussion. For now the cluster stack and dlm components have been placed in their respective directories within the "ocfs2" subdirectory. A major goal in the design of OCFS2 was to make configuration of the entire stack as painless as possible. There is only one configuration file required which describes all nodes in an OCFS2 cluster (/etc/ocfs2/cluster.conf). The cluster.conf file is the same for all nodes so that it can be easily re-copied when changed. Anyone wanting to use OCFS2 should download the tool chain from http://oss.oracle.com/projects/ocfs2-tools/source.html The current OCFS2-tools package includes a full set of standard file system utilities (mkfs.ocfs2, fsck.ocfs2, mount.ocfs2, tunefs.ocfs2, debugfs.ocfs). Pulling down the latest subversion tree is usually best. Setup is quite simple, after software installation, either hand create a configuration or use the "ocfs2console" program to generate one for you. Currently the code should be considered beta quality. The OCFS2 team is deep in a cycle of bug fixing and performance evaluation. As a proof of concept, we've been able to bring up a 12 node shared root cluster. Already, performance on the file system looks promising. A parallel kernel build (make -j4 bzImage on each node within their own trees) compares well with ext3: Ext3 OCFS2 node1 13m4s 13m16s node2 10m27s 10m38s In case there is any concern about code size, a quick comparison shows the file system and cluster stacks combined size to be not significantly larger than reiserfs and 1/3 the size of xfs. For people using git, these changes can be pulled from: http://oss.oracle.com/git/ocfs2.git/ A full patch can be downloaded from: http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/complete/ocfs2-configfs-all.patch Broken out versions of the patches can be found at: http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/ A short description of each patch follows. The same descriptions can be found at the top of each patch file. http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/01_configfs.patch Configfs, a file system for userspace-driven kernel object configuration. The OCFS2 stack makes extensive use of this for propagation of cluster configuration information into kernel. http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/02_mlog.patch Very simple printk wrapper which adds the ability to enable various sets of debug messages at run-time. http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/03_nm.patch A simple node information service, filled and updated from userspace. The rest of the stack queries this service for simple node information. http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/04_heartbeat.patch Disk based heartbeat. Configured and started from userspace, the kernel component handles I/O submission and event generation via callback mechanism. http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/05_messaging.patch Node messaging via tcp. Used by the dlm and the file system for point to point communication between nodes. http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/06_dlm.patch A distributed lock manager built with the cluster file system use case in mind. The OCFS2 dlm exposes a VMS style API, though things have been simplified internally. The only lock levels implemented currently are NLMODE, PRMODE and EXMODE. http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/07_dlmfs.patch dlmfs: A minimal dlm userspace interface implemented via a virtual file system. Most of the OCFS2 tools make use of this to take cluster locks when doing operations on the file system. http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/08_ocfs2.patch The OCFS2 file system module. http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-out/09_build.patch Link the code into the kernel build system. OCFS2 is marked as experimental and we only enable builds on x86, x86-64 and ia64 - endianness consistency is a work in progress. When built, the stack will result in 5 modules: configfs.ko, ocfs2_nodemanager.ko, ocfs2_dlm.ko, ocfs2.ko and ocfs2_dlmfs.ko -- Mark Fasheh Senior Software Developer, Oracle mark.fasheh@oracle.com ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 2005-05-18 22:33 ` Mark Fasheh @ 2005-05-18 23:40 ` Adrian Bunk -1 siblings, 0 replies; 42+ messages in thread From: Adrian Bunk @ 2005-05-18 19:56 UTC (permalink / raw) To: Mark Fasheh Cc: linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb On Wed, May 18, 2005 at 03:33:03PM -0700, Mark Fasheh wrote: >... > A full patch can be downloaded from: > http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/complete/ocfs2-configfs-all.patch >... Some comments on this patch: - there's no reason to make JBD user-visible - is there any reason why CONFIGFS_FS is user-visible? - some global code might become static: run "make namespacecheck" after compiling the kernel and check the configfs and ocfs2 parts of the output > Mark Fasheh cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [RFC] [PATCH] OCFS2 @ 2005-05-18 23:40 ` Adrian Bunk 0 siblings, 0 replies; 42+ messages in thread From: Adrian Bunk @ 2005-05-18 23:40 UTC (permalink / raw) To: Mark Fasheh Cc: linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb On Wed, May 18, 2005 at 03:33:03PM -0700, Mark Fasheh wrote: >... > A full patch can be downloaded from: > http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/complete/ocfs2-configfs-all.patch >... Some comments on this patch: - there's no reason to make JBD user-visible - is there any reason why CONFIGFS_FS is user-visible? - some global code might become static: run "make namespacecheck" after compiling the kernel and check the configfs and ocfs2 parts of the output > Mark Fasheh cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 2005-05-18 23:40 ` Adrian Bunk @ 2005-05-19 1:26 ` Manish Singh -1 siblings, 0 replies; 42+ messages in thread From: Manish Singh @ 2005-05-18 20:26 UTC (permalink / raw) To: Adrian Bunk Cc: Mark Fasheh, akpm, linux-kernel, torvalds, linux-fsdevel, ocfs2-devel On Thu, May 19, 2005 at 01:40:22AM +0200, Adrian Bunk wrote: > On Wed, May 18, 2005 at 03:33:03PM -0700, Mark Fasheh wrote: > >... > > A full patch can be downloaded from: > > http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/complete/ocfs2-configfs-all.patch > >... > > Some comments on this patch: > - there's no reason to make JBD user-visible Sure, the only reason I made it visible was because of the comment in there: # CONFIG_JBD could be its own option (even modular), but until there are # other users than ext3, we will simply make it be the same as CONFIG_EXT3_FS I don't really have a preference either way. > - is there any reason why CONFIGFS_FS is user-visible? It's a generic mechanism for userspace driven configuration of kernel functionality. There's nothing specific to OCFS2 about it. Other kernel subsystems/projects could use it too, for their own configuration mechanisms. More details are in configfs.txt, which is included in the above patch. Note the example used in the documentation text is an NBD driver. > - some global code might become static: > run "make namespacecheck" after compiling the kernel and check > the configfs and ocfs2 parts of the output Yeah, there's some stuff that that scripts catches. Thanks. -Manish ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 @ 2005-05-19 1:26 ` Manish Singh 0 siblings, 0 replies; 42+ messages in thread From: Manish Singh @ 2005-05-19 1:26 UTC (permalink / raw) To: Adrian Bunk Cc: Mark Fasheh, akpm, linux-kernel, torvalds, linux-fsdevel, ocfs2-devel On Thu, May 19, 2005 at 01:40:22AM +0200, Adrian Bunk wrote: > On Wed, May 18, 2005 at 03:33:03PM -0700, Mark Fasheh wrote: > >... > > A full patch can be downloaded from: > > http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/complete/ocfs2-configfs-all.patch > >... > > Some comments on this patch: > - there's no reason to make JBD user-visible Sure, the only reason I made it visible was because of the comment in there: # CONFIG_JBD could be its own option (even modular), but until there are # other users than ext3, we will simply make it be the same as CONFIG_EXT3_FS I don't really have a preference either way. > - is there any reason why CONFIGFS_FS is user-visible? It's a generic mechanism for userspace driven configuration of kernel functionality. There's nothing specific to OCFS2 about it. Other kernel subsystems/projects could use it too, for their own configuration mechanisms. More details are in configfs.txt, which is included in the above patch. Note the example used in the documentation text is an NBD driver. > - some global code might become static: > run "make namespacecheck" after compiling the kernel and check > the configfs and ocfs2 parts of the output Yeah, there's some stuff that that scripts catches. Thanks. -Manish ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 2005-05-19 1:26 ` Manish Singh @ 2005-05-19 9:45 ` Adrian Bunk -1 siblings, 0 replies; 42+ messages in thread From: Adrian Bunk @ 2005-05-19 4:59 UTC (permalink / raw) To: Manish Singh Cc: Mark Fasheh, akpm, linux-kernel, torvalds, linux-fsdevel, ocfs2-devel On Wed, May 18, 2005 at 06:26:58PM -0700, Manish Singh wrote: > On Thu, May 19, 2005 at 01:40:22AM +0200, Adrian Bunk wrote: > > On Wed, May 18, 2005 at 03:33:03PM -0700, Mark Fasheh wrote: > > >... > > > A full patch can be downloaded from: > > > http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/complete/ocfs2-configfs-all.patch > > >... > > > > Some comments on this patch: > > - there's no reason to make JBD user-visible > > Sure, the only reason I made it visible was because of the comment in > there: > > # CONFIG_JBD could be its own option (even modular), but until there are > # other users than ext3, we will simply make it be the same as CONFIG_EXT3_FS > > I don't really have a preference either way. I'd say the comment is wrong. > > - is there any reason why CONFIGFS_FS is user-visible? > > It's a generic mechanism for userspace driven configuration of kernel > functionality. There's nothing specific to OCFS2 about it. Other kernel > subsystems/projects could use it too, for their own configuration > mechanisms. More details are in configfs.txt, which is included in the > above patch. Note the example used in the documentation text is an NBD > driver. >... If other subsystems use it, they should select it. > -Manish cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 @ 2005-05-19 9:45 ` Adrian Bunk 0 siblings, 0 replies; 42+ messages in thread From: Adrian Bunk @ 2005-05-19 9:45 UTC (permalink / raw) To: Manish Singh Cc: Mark Fasheh, akpm, linux-kernel, torvalds, linux-fsdevel, ocfs2-devel On Wed, May 18, 2005 at 06:26:58PM -0700, Manish Singh wrote: > On Thu, May 19, 2005 at 01:40:22AM +0200, Adrian Bunk wrote: > > On Wed, May 18, 2005 at 03:33:03PM -0700, Mark Fasheh wrote: > > >... > > > A full patch can be downloaded from: > > > http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/complete/ocfs2-configfs-all.patch > > >... > > > > Some comments on this patch: > > - there's no reason to make JBD user-visible > > Sure, the only reason I made it visible was because of the comment in > there: > > # CONFIG_JBD could be its own option (even modular), but until there are > # other users than ext3, we will simply make it be the same as CONFIG_EXT3_FS > > I don't really have a preference either way. I'd say the comment is wrong. > > - is there any reason why CONFIGFS_FS is user-visible? > > It's a generic mechanism for userspace driven configuration of kernel > functionality. There's nothing specific to OCFS2 about it. Other kernel > subsystems/projects could use it too, for their own configuration > mechanisms. More details are in configfs.txt, which is included in the > above patch. Note the example used in the documentation text is an NBD > driver. >... If other subsystems use it, they should select it. > -Manish cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 42+ messages in thread
* 2.4 kernel threads 2005-05-19 9:45 ` Adrian Bunk (?) @ 2005-05-19 10:24 ` linux 2005-05-19 10:39 ` Arjan van de Ven 2005-05-19 16:19 ` Jesse Barnes -1 siblings, 2 replies; 42+ messages in thread From: linux @ 2005-05-19 10:24 UTC (permalink / raw) To: lkml While attempting to unload the kernel module which has created a kernel thread whoch runs perfectly i get this oops: Unable to handle kernel paging request at virtual address d08f364c printing eip: c011d6ff *pde = 01af0067 *pte = 00000000 Oops: 0002 parport_pc lp parport autofs pcnet_cs 8390 crc32 ds yenta_socket pcmcia_core floppy microcode ext3 jbd CPU: 0 EIP: 0060:[<c011d6ff>] Not tainted EFLAGS: 00010092 EIP is at interruptible_sleep_on_timeout [kernel] 0x4f (2.4.21-4.EL) eax: d08f3648 ebx: 00000286 ecx: 00000286 edx: d08f3648 esi: 000001c3 edi: 00000000 ebp: cc445fdc esp: cc445fb4 ds: 0068 es: 0068 ss: 0068 Process enigma (pid: 1622, stackpage=cc445000) Stack: 00000000 cc444000 d08f3648 d08f3648 00000000 00000003 00000656 00000656 d08f3060 00000000 cc445fec d08f310d 00000004 cc444000 00000000 c010945d d08f363c 00000000 00000000 Call Trace: [<c010945d>] kernel_thread_helper [kernel] 0x5 (0xcc445ff0) Code: 89 50 04 89 02 c7 45 e4 00 00 00 00 c7 45 e0 00 00 00 00 53 Kernel panic: Fatal exception The module is being unloaded with the following procedure: lock_kernel(); flag=1; /* This flag does a break in the for(;;) loop of the thread after the interruptible_sleep_on_timeout , after the break current=NULL;*/ mb(); kill_proc(pid_thread,SIGKILL,1); unlock_kernel(); kill_proc(2,SIGCHLD,1); /* assuming that keventd is running with PID 2 */ ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.4 kernel threads 2005-05-19 10:24 ` 2.4 kernel threads linux @ 2005-05-19 10:39 ` Arjan van de Ven 2005-05-19 16:19 ` Jesse Barnes 1 sibling, 0 replies; 42+ messages in thread From: Arjan van de Ven @ 2005-05-19 10:39 UTC (permalink / raw) To: linux; +Cc: lkml On Thu, 2005-05-19 at 13:24 +0300, linux wrote: > While attempting to unload the kernel module which has created a kernel > thread whoch runs perfectly i get this oops: you failed to put in an URL to the sourcecode of your module. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.4 kernel threads 2005-05-19 10:24 ` 2.4 kernel threads linux 2005-05-19 10:39 ` Arjan van de Ven @ 2005-05-19 16:19 ` Jesse Barnes 1 sibling, 0 replies; 42+ messages in thread From: Jesse Barnes @ 2005-05-19 16:19 UTC (permalink / raw) To: linux, linux-kernel On Thursday, May 19, 2005 3:24 am, you wrote: > While attempting to unload the kernel module which has created a > kernel thread whoch runs perfectly i get this oops: > Unable to handle kernel paging request at virtual address d08f364c Your messages keep showing up as replies to other threads. It looks like you're just hitting 'reply' to the latest message in your lkml mailbox in order to post a new message (at least the headers of your mail contain references to unrelated messages). Please don't do this. Just create a new message with 'linux-kernel@vger.kernel.org' in the To field. People will be more likely to see your message this way since it won't be buried in a thread they may or may not be interested in. Thanks, Jesse ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 2005-05-18 22:33 ` Mark Fasheh @ 2005-05-18 23:35 ` Hans Reiser -1 siblings, 0 replies; 42+ messages in thread From: Hans Reiser @ 2005-05-18 19:56 UTC (permalink / raw) To: Mark Fasheh Cc: linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb Mark Fasheh wrote: >In case there is any concern about code size, a quick comparison shows >the file system and cluster stacks combined size to be not >significantly larger than reiserfs and 1/3 the size of xfs. > > > I too am quick to cite XFS when anyone complains about the code size of anything we write.;-) Congrats on getting a filesystem to start to work, I know how long that road is, and best of luck to you all, Hans ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [RFC] [PATCH] OCFS2 @ 2005-05-18 23:35 ` Hans Reiser 0 siblings, 0 replies; 42+ messages in thread From: Hans Reiser @ 2005-05-18 23:35 UTC (permalink / raw) To: Mark Fasheh Cc: linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb Mark Fasheh wrote: >In case there is any concern about code size, a quick comparison shows >the file system and cluster stacks combined size to be not >significantly larger than reiserfs and 1/3 the size of xfs. > > > I too am quick to cite XFS when anyone complains about the code size of anything we write.;-) Congrats on getting a filesystem to start to work, I know how long that road is, and best of luck to you all, Hans ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 2005-05-18 22:33 ` Mark Fasheh @ 2005-05-19 2:30 ` Kyle Moffett -1 siblings, 0 replies; 42+ messages in thread From: Kyle Moffett @ 2005-05-18 23:28 UTC (permalink / raw) To: Mark Fasheh Cc: linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb On May 18, 2005, at 18:33:03, Mark Fasheh wrote: > Hello, > > This is OCFS2, a shared disk cluster file system which we hope will be > included in the kernel. > > We think OCFS2 has many qualities which make it particularly > interesting as a cluster file system: [...snip...] > -OCFS2 has a strong data locking model, which includes a shared mmap > implementation (shared writeable mappings are not yet supported) and > full AIO support. Does this include support for UNIX sockets and named pipes? One of the issues I have with filesystems like AFS and NFS is that they should theoretically make such things possible, but the code is not implemented yet and does not appear it ever will be. This is very useful for home directories when using programs like "links" that rely on being able to create UNIX sockets in .links/socket or similar. Cheers, Kyle Moffett -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$ L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-) ------END GEEK CODE BLOCK------ ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [RFC] [PATCH] OCFS2 @ 2005-05-19 2:30 ` Kyle Moffett 0 siblings, 0 replies; 42+ messages in thread From: Kyle Moffett @ 2005-05-19 2:30 UTC (permalink / raw) To: Mark Fasheh Cc: linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb On May 18, 2005, at 18:33:03, Mark Fasheh wrote: > Hello, > > This is OCFS2, a shared disk cluster file system which we hope will be > included in the kernel. > > We think OCFS2 has many qualities which make it particularly > interesting as a cluster file system: [...snip...] > -OCFS2 has a strong data locking model, which includes a shared mmap > implementation (shared writeable mappings are not yet supported) and > full AIO support. Does this include support for UNIX sockets and named pipes? One of the issues I have with filesystems like AFS and NFS is that they should theoretically make such things possible, but the code is not implemented yet and does not appear it ever will be. This is very useful for home directories when using programs like "links" that rely on being able to create UNIX sockets in .links/socket or similar. Cheers, Kyle Moffett -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$ L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-) ------END GEEK CODE BLOCK------ ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 2005-05-19 2:30 ` Kyle Moffett @ 2005-05-19 4:30 ` Mark Fasheh -1 siblings, 0 replies; 42+ messages in thread From: Mark Fasheh @ 2005-05-18 23:30 UTC (permalink / raw) To: Kyle Moffett Cc: linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb On Wed, May 18, 2005 at 10:30:56PM -0400, Kyle Moffett wrote: > Does this include support for UNIX sockets and named pipes? Unfortunately no, at least not on a clustered level. Local node, those should work as normal. If you absolutely need this functionality, I believe OpenSSI currently supports it. If you're looking for an easy way to share small amounts data between applications in an OCFS2 cluster, you might be interested in looking at dlmfs. Once mounted, it's quite trivial to create dlm domains and lock resources between nodes via regular file system operations (open, close, etc). File read and write will return and set the resource LVB for you, currently 64 bytes. Though this can all be controlled from shell, a small library (libo2cb) to take advantage of this is provided in the current toolchain distribution. --Mark -- Mark Fasheh Senior Software Developer, Oracle mark.fasheh@oracle.com ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [RFC] [PATCH] OCFS2 @ 2005-05-19 4:30 ` Mark Fasheh 0 siblings, 0 replies; 42+ messages in thread From: Mark Fasheh @ 2005-05-19 4:30 UTC (permalink / raw) To: Kyle Moffett Cc: linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb On Wed, May 18, 2005 at 10:30:56PM -0400, Kyle Moffett wrote: > Does this include support for UNIX sockets and named pipes? Unfortunately no, at least not on a clustered level. Local node, those should work as normal. If you absolutely need this functionality, I believe OpenSSI currently supports it. If you're looking for an easy way to share small amounts data between applications in an OCFS2 cluster, you might be interested in looking at dlmfs. Once mounted, it's quite trivial to create dlm domains and lock resources between nodes via regular file system operations (open, close, etc). File read and write will return and set the resource LVB for you, currently 64 bytes. Though this can all be controlled from shell, a small library (libo2cb) to take advantage of this is provided in the current toolchain distribution. --Mark -- Mark Fasheh Senior Software Developer, Oracle mark.fasheh@oracle.com ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 2005-05-18 22:33 ` Mark Fasheh @ 2005-05-19 6:30 ` Daniel Phillips -1 siblings, 0 replies; 42+ messages in thread From: Daniel Phillips @ 2005-05-19 1:52 UTC (permalink / raw) To: Mark Fasheh Cc: linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb On Wednesday 18 May 2005 18:33, Mark Fasheh wrote: > http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-o >ut/06_dlm.patch A distributed lock manager built with the cluster file > system use case in mind. The OCFS2 dlm exposes a VMS style API, though > things have been simplified internally. The only lock levels implemented > currently are NLMODE, PRMODE and EXMODE. + if (recovery && + (!dlm_is_recovery_lock(name, strlen(name)) || convert) ) { + goto error; + } Zero terminated strings for lock names is bad taste. It generates a bunch of useless strlen executions and you force an ascii namespace for no apparent reason. Add a 9th parameter, namelen, to the lock call maybe? Regards, Daniel ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [RFC] [PATCH] OCFS2 @ 2005-05-19 6:30 ` Daniel Phillips 0 siblings, 0 replies; 42+ messages in thread From: Daniel Phillips @ 2005-05-19 6:30 UTC (permalink / raw) To: Mark Fasheh Cc: linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb On Wednesday 18 May 2005 18:33, Mark Fasheh wrote: > http://oss.oracle.com/projects/ocfs2/dist/files/patches/2.6.12-rc4/broken-o >ut/06_dlm.patch A distributed lock manager built with the cluster file > system use case in mind. The OCFS2 dlm exposes a VMS style API, though > things have been simplified internally. The only lock levels implemented > currently are NLMODE, PRMODE and EXMODE. + if (recovery && + (!dlm_is_recovery_lock(name, strlen(name)) || convert) ) { + goto error; + } Zero terminated strings for lock names is bad taste. It generates a bunch of useless strlen executions and you force an ascii namespace for no apparent reason. Add a 9th parameter, namelen, to the lock call maybe? Regards, Daniel ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 2005-05-19 6:30 ` Daniel Phillips @ 2005-05-19 6:54 ` Mark Fasheh -1 siblings, 0 replies; 42+ messages in thread From: Mark Fasheh @ 2005-05-19 1:54 UTC (permalink / raw) To: Daniel Phillips Cc: linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb On Thu, May 19, 2005 at 02:30:23AM -0400, Daniel Phillips wrote: > Zero terminated strings for lock names is bad taste. It generates a bunch of > useless strlen executions and you force an ascii namespace for no apparent > reason. Add a 9th parameter, namelen, to the lock call maybe? Or perhaps pass in a qstr? Anyway I have to agree. That shouldn't be difficult to fix up. --Mark -- Mark Fasheh Senior Software Developer, Oracle mark.fasheh@oracle.com ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [RFC] [PATCH] OCFS2 @ 2005-05-19 6:54 ` Mark Fasheh 0 siblings, 0 replies; 42+ messages in thread From: Mark Fasheh @ 2005-05-19 6:54 UTC (permalink / raw) To: Daniel Phillips Cc: linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb On Thu, May 19, 2005 at 02:30:23AM -0400, Daniel Phillips wrote: > Zero terminated strings for lock names is bad taste. It generates a bunch of > useless strlen executions and you force an ascii namespace for no apparent > reason. Add a 9th parameter, namelen, to the lock call maybe? Or perhaps pass in a qstr? Anyway I have to agree. That shouldn't be difficult to fix up. --Mark -- Mark Fasheh Senior Software Developer, Oracle mark.fasheh@oracle.com ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 2005-05-19 6:54 ` Mark Fasheh @ 2005-05-19 16:23 ` Daniel Phillips -1 siblings, 0 replies; 42+ messages in thread From: Daniel Phillips @ 2005-05-19 11:19 UTC (permalink / raw) To: Mark Fasheh Cc: linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb Hi Mark, On Thursday 19 May 2005 02:54, Mark Fasheh wrote: > On Thu, May 19, 2005 at 02:30:23AM -0400, Daniel Phillips wrote: > > Zero terminated strings for lock names is bad taste. It generates a > > bunch of useless strlen executions and you force an ascii namespace for > > no apparent reason. Add a 9th parameter, namelen, to the lock call > > maybe? > > Or perhaps pass in a qstr? Anyway I have to agree. That shouldn't be > difficult to fix up. Qstr would be nice, either that or an explicit string length. Either way, the compiler will catch any missed fixups. Regards, Daniel ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [RFC] [PATCH] OCFS2 @ 2005-05-19 16:23 ` Daniel Phillips 0 siblings, 0 replies; 42+ messages in thread From: Daniel Phillips @ 2005-05-19 16:23 UTC (permalink / raw) To: Mark Fasheh Cc: linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb Hi Mark, On Thursday 19 May 2005 02:54, Mark Fasheh wrote: > On Thu, May 19, 2005 at 02:30:23AM -0400, Daniel Phillips wrote: > > Zero terminated strings for lock names is bad taste. It generates a > > bunch of useless strlen executions and you force an ascii namespace for > > no apparent reason. Add a 9th parameter, namelen, to the lock call > > maybe? > > Or perhaps pass in a qstr? Anyway I have to agree. That shouldn't be > difficult to fix up. Qstr would be nice, either that or an explicit string length. Either way, the compiler will catch any missed fixups. Regards, Daniel ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [RFC] [PATCH] OCFS2 2005-05-19 6:30 ` Daniel Phillips @ 2005-05-19 15:09 ` Jeff Garzik -1 siblings, 0 replies; 42+ messages in thread From: Jeff Garzik @ 2005-05-19 10:26 UTC (permalink / raw) To: Daniel Phillips Cc: Mark Fasheh, linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb Daniel Phillips wrote: > Zero terminated strings for lock names is bad taste. It generates a bunch of > useless strlen executions and you force an ascii namespace for no apparent > reason. Add a 9th parameter, namelen, to the lock call maybe? What's wrong with ascii strings? We call those 'UTF8' these days. Jeff ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 @ 2005-05-19 15:09 ` Jeff Garzik 0 siblings, 0 replies; 42+ messages in thread From: Jeff Garzik @ 2005-05-19 15:09 UTC (permalink / raw) To: Daniel Phillips Cc: Mark Fasheh, linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb Daniel Phillips wrote: > Zero terminated strings for lock names is bad taste. It generates a bunch of > useless strlen executions and you force an ascii namespace for no apparent > reason. Add a 9th parameter, namelen, to the lock call maybe? What's wrong with ascii strings? We call those 'UTF8' these days. Jeff ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 2005-05-19 15:09 ` [Ocfs2-devel] " Jeff Garzik @ 2005-05-19 15:20 ` Lee Revell -1 siblings, 0 replies; 42+ messages in thread From: Lee Revell @ 2005-05-19 15:09 UTC (permalink / raw) To: Jeff Garzik Cc: Daniel Phillips, Mark Fasheh, linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb On Thu, 2005-05-19 at 06:26 -0400, Jeff Garzik wrote: > Daniel Phillips wrote: > > Zero terminated strings for lock names is bad taste. It generates a bunch of > > useless strlen executions and you force an ascii namespace for no apparent > > reason. Add a 9th parameter, namelen, to the lock call maybe? > > What's wrong with ascii strings? > > We call those 'UTF8' these days. I think you just answered your own question. Lee ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [RFC] [PATCH] OCFS2 @ 2005-05-19 15:20 ` Lee Revell 0 siblings, 0 replies; 42+ messages in thread From: Lee Revell @ 2005-05-19 15:20 UTC (permalink / raw) To: Jeff Garzik Cc: Daniel Phillips, Mark Fasheh, linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb On Thu, 2005-05-19 at 06:26 -0400, Jeff Garzik wrote: > Daniel Phillips wrote: > > Zero terminated strings for lock names is bad taste. It generates a bunch of > > useless strlen executions and you force an ascii namespace for no apparent > > reason. Add a 9th parameter, namelen, to the lock call maybe? > > What's wrong with ascii strings? > > We call those 'UTF8' these days. I think you just answered your own question. Lee ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 2005-05-19 15:20 ` Lee Revell @ 2005-05-19 15:25 ` Jeff Garzik -1 siblings, 0 replies; 42+ messages in thread From: Jeff Garzik @ 2005-05-19 15:09 UTC (permalink / raw) To: Lee Revell Cc: Daniel Phillips, Mark Fasheh, linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb Lee Revell wrote: > On Thu, 2005-05-19 at 06:26 -0400, Jeff Garzik wrote: > >>Daniel Phillips wrote: >> >>>Zero terminated strings for lock names is bad taste. It generates a bunch of >>>useless strlen executions and you force an ascii namespace for no apparent >>>reason. Add a 9th parameter, namelen, to the lock call maybe? >> >>What's wrong with ascii strings? >> >>We call those 'UTF8' these days. > > > I think you just answered your own question. Incorrect. Read the quoted context. Jeff ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [RFC] [PATCH] OCFS2 @ 2005-05-19 15:25 ` Jeff Garzik 0 siblings, 0 replies; 42+ messages in thread From: Jeff Garzik @ 2005-05-19 15:25 UTC (permalink / raw) To: Lee Revell Cc: Daniel Phillips, Mark Fasheh, linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb Lee Revell wrote: > On Thu, 2005-05-19 at 06:26 -0400, Jeff Garzik wrote: > >>Daniel Phillips wrote: >> >>>Zero terminated strings for lock names is bad taste. It generates a bunch of >>>useless strlen executions and you force an ascii namespace for no apparent >>>reason. Add a 9th parameter, namelen, to the lock call maybe? >> >>What's wrong with ascii strings? >> >>We call those 'UTF8' these days. > > > I think you just answered your own question. Incorrect. Read the quoted context. Jeff ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 2005-05-18 22:33 ` Mark Fasheh @ 2005-06-23 18:03 ` James Morris -1 siblings, 0 replies; 42+ messages in thread From: James Morris @ 2005-06-23 13:03 UTC (permalink / raw) To: Mark Fasheh Cc: linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb On Wed, 18 May 2005, Mark Fasheh wrote: > This is OCFS2, a shared disk cluster file system which we hope will be > included in the kernel. The masklog code looks potentially useful outside of ocfs2, as a general kernel facility. Any chance of splitting it out? Quibbles: - A lot of the macros should probably be replaced with static inlines, like OCFS2_IS_VALID_DINODE. - Approx. 80 typedefs. ouch. -- James Morris <jmorris@redhat.com> ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [RFC] [PATCH] OCFS2 @ 2005-06-23 18:03 ` James Morris 0 siblings, 0 replies; 42+ messages in thread From: James Morris @ 2005-06-23 18:03 UTC (permalink / raw) To: Mark Fasheh Cc: linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb On Wed, 18 May 2005, Mark Fasheh wrote: > This is OCFS2, a shared disk cluster file system which we hope will be > included in the kernel. The masklog code looks potentially useful outside of ocfs2, as a general kernel facility. Any chance of splitting it out? Quibbles: - A lot of the macros should probably be replaced with static inlines, like OCFS2_IS_VALID_DINODE. - Approx. 80 typedefs. ouch. -- James Morris <jmorris@redhat.com> ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 2005-06-23 18:03 ` James Morris @ 2005-06-23 18:29 ` Mark Fasheh -1 siblings, 0 replies; 42+ messages in thread From: Mark Fasheh @ 2005-06-23 13:29 UTC (permalink / raw) To: James Morris Cc: linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb Hi James, Thanks for looking over this. On Thu, Jun 23, 2005 at 02:03:35PM -0400, James Morris wrote: > The masklog code looks potentially useful outside of ocfs2, as a general > kernel facility. Any chance of splitting it out? Absolutely. We've found that stuff invaluable in debugging issues for a while now, and as far as I recall, Zach wrote it with the idea that it could be useful to other folks too. I think the only issue to resolve there would be how other subsystems reserve a debugging bit... > Quibbles: > > - A lot of the macros should probably be replaced with static inlines, > like OCFS2_IS_VALID_DINODE. > > - Approx. 80 typedefs. ouch. Heh, we're slowly removing those :) --Mark -- Mark Fasheh Senior Software Developer, Oracle mark.fasheh@oracle.com ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [RFC] [PATCH] OCFS2 @ 2005-06-23 18:29 ` Mark Fasheh 0 siblings, 0 replies; 42+ messages in thread From: Mark Fasheh @ 2005-06-23 18:29 UTC (permalink / raw) To: James Morris Cc: linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb Hi James, Thanks for looking over this. On Thu, Jun 23, 2005 at 02:03:35PM -0400, James Morris wrote: > The masklog code looks potentially useful outside of ocfs2, as a general > kernel facility. Any chance of splitting it out? Absolutely. We've found that stuff invaluable in debugging issues for a while now, and as far as I recall, Zach wrote it with the idea that it could be useful to other folks too. I think the only issue to resolve there would be how other subsystems reserve a debugging bit... > Quibbles: > > - A lot of the macros should probably be replaced with static inlines, > like OCFS2_IS_VALID_DINODE. > > - Approx. 80 typedefs. ouch. Heh, we're slowly removing those :) --Mark -- Mark Fasheh Senior Software Developer, Oracle mark.fasheh@oracle.com ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [RFC] [PATCH] OCFS2 2005-06-23 18:03 ` James Morris @ 2005-06-24 15:34 ` Paul Jackson -1 siblings, 0 replies; 42+ messages in thread From: Paul Jackson @ 2005-06-24 3:05 UTC (permalink / raw) To: James Morris Cc: mark.fasheh, linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb James wrote: > Any chance of splitting it out? Responding to your post, but I guess it's really Oracle I'm asking: On my first glance just now at the git-ocfs patch, I was surprised that what seemed to be separable facilities were combined into one patch. I see a file system, a lock manager (is that what DLM stands for - please spell out acronyms) and a configuration file system. +configfs/ + - directory containing configfs documentation and example code. ... +dlmfs.txt + - info on the userspace interface to the OCFS2 DLM. ... +ocfs2.txt + - info and mount options for the OCFS2 clustered filesystem. These combine to make a 45 thousand line patch. That's a big patch. Only the netdev and reiser4 patches (and the combined linus.patch) are bigger. Shouldn't these be 3 patches, or more? -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.925.600.0401 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 @ 2005-06-24 15:34 ` Paul Jackson 0 siblings, 0 replies; 42+ messages in thread From: Paul Jackson @ 2005-06-24 15:34 UTC (permalink / raw) To: James Morris Cc: mark.fasheh, linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb James wrote: > Any chance of splitting it out? Responding to your post, but I guess it's really Oracle I'm asking: On my first glance just now at the git-ocfs patch, I was surprised that what seemed to be separable facilities were combined into one patch. I see a file system, a lock manager (is that what DLM stands for - please spell out acronyms) and a configuration file system. +configfs/ + - directory containing configfs documentation and example code. ... +dlmfs.txt + - info on the userspace interface to the OCFS2 DLM. ... +ocfs2.txt + - info and mount options for the OCFS2 clustered filesystem. These combine to make a 45 thousand line patch. That's a big patch. Only the netdev and reiser4 patches (and the combined linus.patch) are bigger. Shouldn't these be 3 patches, or more? -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.925.600.0401 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 2005-06-24 15:34 ` [Ocfs2-devel] " Paul Jackson @ 2005-06-24 3:59 ` Mark Fasheh -1 siblings, 0 replies; 42+ messages in thread From: Mark Fasheh @ 2005-06-23 23:00 UTC (permalink / raw) To: Paul Jackson Cc: James Morris, linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb On Thu, Jun 23, 2005 at 08:05:24PM -0700, Paul Jackson wrote: > These combine to make a 45 thousand line patch. That's a big patch. > Only the netdev and reiser4 patches (and the combined linus.patch) > are bigger. > > Shouldn't these be 3 patches, or more? They are. I believe you're looking at the combined patch. If you want them broken out, we keep those at http://oss.oracle.com/projects/ocfs2/files/patches/ My original patch mail also had links to the broken out ones... --Mark -- Mark Fasheh Senior Software Developer, Oracle mark.fasheh@oracle.com ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [RFC] [PATCH] OCFS2 @ 2005-06-24 3:59 ` Mark Fasheh 0 siblings, 0 replies; 42+ messages in thread From: Mark Fasheh @ 2005-06-24 3:59 UTC (permalink / raw) To: Paul Jackson Cc: James Morris, linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb On Thu, Jun 23, 2005 at 08:05:24PM -0700, Paul Jackson wrote: > These combine to make a 45 thousand line patch. That's a big patch. > Only the netdev and reiser4 patches (and the combined linus.patch) > are bigger. > > Shouldn't these be 3 patches, or more? They are. I believe you're looking at the combined patch. If you want them broken out, we keep those at http://oss.oracle.com/projects/ocfs2/files/patches/ My original patch mail also had links to the broken out ones... --Mark -- Mark Fasheh Senior Software Developer, Oracle mark.fasheh@oracle.com ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [RFC] [PATCH] OCFS2 2005-06-24 3:59 ` Mark Fasheh @ 2005-06-24 15:34 ` Paul Jackson -1 siblings, 0 replies; 42+ messages in thread From: Paul Jackson @ 2005-06-24 4:17 UTC (permalink / raw) To: Mark Fasheh Cc: jmorris, linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb Mark wrote: > My original patch mail also had links to the broken out ones... Ok - good. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.925.600.0401 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 @ 2005-06-24 15:34 ` Paul Jackson 0 siblings, 0 replies; 42+ messages in thread From: Paul Jackson @ 2005-06-24 15:34 UTC (permalink / raw) To: Mark Fasheh Cc: jmorris, linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb Mark wrote: > My original patch mail also had links to the broken out ones... Ok - good. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.925.600.0401 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [RFC] [PATCH] OCFS2 2005-06-24 15:34 ` [Ocfs2-devel] " Paul Jackson @ 2005-06-24 15:34 ` Paul Jackson -1 siblings, 0 replies; 42+ messages in thread From: Paul Jackson @ 2005-06-24 3:29 UTC (permalink / raw) To: Paul Jackson Cc: jmorris, mark.fasheh, linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb A couple more random questions: 1) How does this lock manager relate to the Red Hat lock manager, the dlm-* patches? Note as an aside that dlm-* has 23 patches for a total of 14 thousand lines, or about 600 lines per patch. This is rather different than burying a lock manager into a 45 thousand line new file system patch ;) 2) Would a diffstat be a useful addition to this patch? -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.925.600.0401 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 @ 2005-06-24 15:34 ` Paul Jackson 0 siblings, 0 replies; 42+ messages in thread From: Paul Jackson @ 2005-06-24 15:34 UTC (permalink / raw) To: Paul Jackson Cc: jmorris, mark.fasheh, linux-kernel, linux-fsdevel, ocfs2-devel, torvalds, akpm, wim.coekaerts, lmb A couple more random questions: 1) How does this lock manager relate to the Red Hat lock manager, the dlm-* patches? Note as an aside that dlm-* has 23 patches for a total of 14 thousand lines, or about 600 lines per patch. This is rather different than burying a lock manager into a 45 thousand line new file system patch ;) 2) Would a diffstat be a useful addition to this patch? -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.925.600.0401 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 0/8] ppc64: Introduce Cell/BPA platform, v2 @ 2005-05-13 19:31 Arnd Bergmann 2005-05-18 12:40 ` [PATCH] libfs: add simple attribute files Arnd Bergmann 0 siblings, 1 reply; 42+ messages in thread From: Arnd Bergmann @ 2005-05-13 19:31 UTC (permalink / raw) To: linuxppc64-dev Cc: linux-kernel, Paul Mackerras, Anton Blanchard, Benjamin Herrenschmidt This series of patches add support for a fifth platform type in the ppc64 architecture tree. The Broadband Processor Architecture (BPA) is what machines using the Cell processor should be following and currently only prototype hardware exists for it. Except for the last patch, these are functionally the same as the first version but are updated for 2.6.12-rc4 and contain changes based on the feedback I got so far. The first three patches add some infrastructure that is used by BPA machines but is not really specific to them can could be used by other new platform types as well. The next three patches add the actual platform code, which should be usable for any BPA compatible implementation. Patch 7 introduces a new file system to make use of the SPUs inside the processors. This patch is still in a prototype stage and not intended for merging yet. The final patch adds some user space code in the Documentation directory that clarifies how to use the file system. This one should become a separate package at a later point. Arnd <>< ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH] libfs: add simple attribute files @ 2005-05-18 12:40 ` Arnd Bergmann 2005-05-18 20:24 ` Greg KH 0 siblings, 1 reply; 42+ messages in thread From: Arnd Bergmann @ 2005-05-18 12:40 UTC (permalink / raw) To: Greg KH Cc: linuxppc64-dev, linux-kernel, Paul Mackerras, Anton Blanchard, Benjamin Herrenschmidt Based on the discussion about spufs attributes, this is my suggestion for a more generic attribute file support that can be used by both debugfs and spufs. Simple attribute files behave similarly to sequential files from a kernel programmers perspective in that a standard set of file operations is provided and only an open operation needs to be written that registers file specific get() and set() functions. These operations are defined as void foo_set(void *data, long val); and long foo_get(void *data); where data is the inode->u.generic_ip pointer of the file and the operations just need to make send of that pointer. The infrastructure makes sure this works correctly with concurrent access and partial read calls. A macro named DEFINE_SIMPLE_ATTRIBUTE is provided to further simplify using the attributes. This patch already contains the changes for debugfs to use attributes for its internal file operations. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- fs/debugfs/file.c | 74 +++++++++++++++++++---------------------- fs/libfs.c | 94 +++++++++++++++++++++++++++++++++++++++++++++++++++++ include/linux/fs.h | 48 +++++++++++++++++++++++++++ 3 files changed, 177 insertions(+), 39 deletions(-) fs/libfs.c: needs update Index: linus-2.5/include/linux/fs.h =================================================================== --- linus-2.5.orig/include/linux/fs.h 2005-05-18 10:58:52.000000000 +0200 +++ linus-2.5/include/linux/fs.h 2005-05-18 14:07:10.000000000 +0200 @@ -1657,6 +1657,55 @@ ar->size = n; } +/* + * simple attribute files + * + * These attributes behave similar to those in sysfs: + * + * Writing to an attribute immediately sets a value, an open file can be + * written to multiple times. + * + * Reading from an attribute creates a buffer from the value that might get + * read with multiple read calls. When the attribute has been read + * completely, no further read calls are possible until the file is opened + * again. + * + * All spufs attributes contain a text representation of a numeric value + * that are accessed with the get() and set() functions. + * + * Perhaps these file operations could be put in debugfs or libfs instead, + * they are not really SPU specific. + */ +#define DEFINE_SIMPLE_ATTRIBUTE(__fops, __get, __set, __fmt) \ +static int __fops ## _open(struct inode *inode, struct file *file) \ +{ \ + __simple_attr_check_format(__fmt, 0ul); \ + return simple_attr_open(inode, file, &__get, &__set, __fmt); \ +} \ +static struct file_operations __fops = { \ + .owner = THIS_MODULE, \ + .open = __fops ## _open, \ + .release = simple_attr_close, \ + .read = simple_attr_read, \ + .write = simple_attr_write, \ +}; + +static inline void __attribute__((format(printf, 1, 2))) +__simple_attr_check_format(const char *fmt, ...) +{ + /* don't do anything, just let the compiler check the arguments; */ +} + +int simple_attr_open(struct inode *inode, struct file *file, + long (*get)(void *), void (*set)(void *, long), + const char *fmt); +int simple_attr_close(struct inode *inode, struct file *file); +ssize_t simple_attr_read(struct file *file, char __user *buf, + size_t len, loff_t *ppos); +ssize_t simple_attr_write(struct file *file, const char __user *buf, + size_t len, loff_t *ppos); + + #ifdef CONFIG_SECURITY static inline char *alloc_secdata(void) { Index: linus-2.5/fs/libfs.c =================================================================== --- linus-2.5.orig/fs/libfs.c 2005-05-18 10:58:52.000000000 +0200 +++ linus-2.5/fs/libfs.c 2005-05-18 12:06:49.000000000 +0200 @@ -519,6 +519,100 @@ return 0; } +/* Simple attribute files */ + +struct simple_attr { + long (*get)(void *); + void (*set)(void *, long); + char get_buf[24]; /* enough to store a long and "\n\0" */ + char set_buf[24]; + void *data; + const char *fmt; /* format for read operation */ + struct semaphore sem; /* protects access to these buffers */ +}; + +/* simple_attr_open is called by an actual attribute open file operation + * to set the attribute specific access operations. */ +int simple_attr_open(struct inode *inode, struct file *file, + long (*get)(void *), void (*set)(void *, long), + const char *fmt) +{ + struct simple_attr *attr; + + attr = kmalloc(sizeof *attr, GFP_KERNEL); + if (!attr) + return -ENOMEM; + + /* reading/writing needs the respective get/set operation */ + if (((file->f_mode & FMODE_READ) && !get) || + ((file->f_mode & FMODE_WRITE) && !set)) + return -EACCES; + + attr->get = get; + attr->set = set; + attr->data = inode->u.generic_ip; + attr->fmt = fmt; + init_MUTEX(&attr->sem); + + file->private_data = attr; + + return nonseekable_open(inode, file); +} + +int simple_attr_close(struct inode *inode, struct file *file) +{ + kfree(file->private_data); + return 0; +} + +/* read from the buffer that is filled with the get function */ +ssize_t simple_attr_read(struct file *file, char __user *buf, + size_t len, loff_t *ppos) +{ + struct simple_attr *attr; + size_t size; + ssize_t ret; + + attr = file->private_data; + + down(&attr->sem); + if (*ppos) /* continued read */ + size = strlen(attr->get_buf); + else /* first read */ + size = scnprintf(attr->get_buf, sizeof (attr->get_buf), + attr->fmt, attr->get(attr->data)); + + ret = simple_read_from_buffer(buf, len, ppos, attr->get_buf, size); + up(&attr->sem); + return ret; +} + +/* interpret the buffer as a number to call the set function with */ +ssize_t simple_attr_write(struct file *file, const char __user *buf, + size_t len, loff_t *ppos) +{ + struct simple_attr *attr; + long val; + size_t size; + ssize_t ret; + + attr = file->private_data; + + down(&attr->sem); + ret = -EFAULT; + size = min(sizeof (attr->set_buf) - 1, len); + if (copy_from_user(attr->set_buf, buf, size)) + goto out; + + ret = len; /* claim we got the whole input */ + attr->set_buf[size] = '\0'; + val = simple_strtol(attr->set_buf, NULL, 0); + attr->set(attr->data, val); +out: + up(&attr->sem); + return ret; +} + EXPORT_SYMBOL(dcache_dir_close); EXPORT_SYMBOL(dcache_dir_lseek); EXPORT_SYMBOL(dcache_dir_open); Index: linus-2.5/fs/debugfs/file.c =================================================================== --- linus-2.5.orig/fs/debugfs/file.c 2005-05-18 10:58:52.000000000 +0200 +++ linus-2.5/fs/debugfs/file.c 2005-05-18 12:22:16.000000000 +0200 @@ -45,45 +45,6 @@ .open = default_open, }; -#define simple_type(type, format, temptype, strtolfn) \ -static ssize_t read_file_##type(struct file *file, char __user *user_buf, \ - size_t count, loff_t *ppos) \ -{ \ - char buf[32]; \ - type *val = file->private_data; \ - \ - snprintf(buf, sizeof(buf), format "\n", *val); \ - return simple_read_from_buffer(user_buf, count, ppos, buf, strlen(buf));\ -} \ -static ssize_t write_file_##type(struct file *file, const char __user *user_buf,\ - size_t count, loff_t *ppos) \ -{ \ - char *endp; \ - char buf[32]; \ - int buf_size; \ - type *val = file->private_data; \ - temptype tmp; \ - \ - memset(buf, 0x00, sizeof(buf)); \ - buf_size = min(count, (sizeof(buf)-1)); \ - if (copy_from_user(buf, user_buf, buf_size)) \ - return -EFAULT; \ - \ - tmp = strtolfn(buf, &endp, 0); \ - if ((endp == buf) || ((type)tmp != tmp)) \ - return -EINVAL; \ - *val = tmp; \ - return count; \ -} \ -static struct file_operations fops_##type = { \ - .read = read_file_##type, \ - .write = write_file_##type, \ - .open = default_open, \ -}; -simple_type(u8, "%c", unsigned long, simple_strtoul); -simple_type(u16, "%hi", unsigned long, simple_strtoul); -simple_type(u32, "%i", unsigned long, simple_strtoul); - /** * debugfs_create_u8 - create a file in the debugfs filesystem that is used to read and write a unsigned 8 bit value. * @@ -109,6 +70,18 @@ * NULL or !NULL instead as to eliminate the need for #ifdef in the calling * code. */ +static void debugfs_u8_set(void *data, long val) +{ + *(u8 *)data = val; +} + +static long debugfs_u8_get(void *data) +{ + return *(u8 *)data; +} + +DEFINE_SIMPLE_ATTRIBUTE(fops_u8, debugfs_u8_get, debugfs_u8_set, "%lu\n"); + struct dentry *debugfs_create_u8(const char *name, mode_t mode, struct dentry *parent, u8 *value) { @@ -141,6 +114,17 @@ * NULL or !NULL instead as to eliminate the need for #ifdef in the calling * code. */ +static void debugfs_u16_set(void *data, long val) +{ + *(u16 *)data = val; +} + +static long debugfs_u16_get(void *data) +{ + return *(u16 *)data; +} +DEFINE_SIMPLE_ATTRIBUTE(fops_u16, debugfs_u16_get, debugfs_u16_set, "%lu\n"); + struct dentry *debugfs_create_u16(const char *name, mode_t mode, struct dentry *parent, u16 *value) { @@ -173,6 +157,18 @@ * NULL or !NULL instead as to eliminate the need for #ifdef in the calling * code. */ +static void debugfs_u32_set(void *data, long val) +{ + *(u32 *)data = val; +} + +static long debugfs_u32_get(void *data) +{ + return *(u32 *)data; +} + +DEFINE_SIMPLE_ATTRIBUTE(fops_u32, debugfs_u32_get, debugfs_u32_set, "%lu\n"); + struct dentry *debugfs_create_u32(const char *name, mode_t mode, struct dentry *parent, u32 *value) { ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] libfs: add simple attribute files 2005-05-18 12:40 ` [PATCH] libfs: add simple attribute files Arnd Bergmann @ 2005-05-18 20:24 ` Greg KH 2005-05-19 8:29 ` Arnd Bergmann 0 siblings, 1 reply; 42+ messages in thread From: Greg KH @ 2005-05-18 20:24 UTC (permalink / raw) To: Arnd Bergmann Cc: linuxppc64-dev, linux-kernel, Paul Mackerras, Anton Blanchard, Benjamin Herrenschmidt On Wed, May 18, 2005 at 02:40:59PM +0200, Arnd Bergmann wrote: > Based on the discussion about spufs attributes, this is my suggestion > for a more generic attribute file support that can be used by both > debugfs and spufs. Thanks for the patch. I've cleaned it up a bit (drop the spufs comments, changed the access check, and made the val be u64, and exported the symbols and cleaned up the debugfs portion) and added it to my tree. It should show up in the next -mm release. I've included the patch below so you can see my changes. thanks, greg k-h --------------- Based on the discussion about spufs attributes, this is my suggestion for a more generic attribute file support that can be used by both debugfs and spufs. Simple attribute files behave similarly to sequential files from a kernel programmers perspective in that a standard set of file operations is provided and only an open operation needs to be written that registers file specific get() and set() functions. These operations are defined as void foo_set(void *data, long val); and long foo_get(void *data); where data is the inode->u.generic_ip pointer of the file and the operations just need to make send of that pointer. The infrastructure makes sure this works correctly with concurrent access and partial read calls. A macro named DEFINE_SIMPLE_ATTRIBUTE is provided to further simplify using the attributes. This patch already contains the changes for debugfs to use attributes for its internal file operations. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- fs/debugfs/file.c | 67 +++++++++++++++-------------------- fs/libfs.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++++++ include/linux/fs.h | 46 ++++++++++++++++++++++++ 3 files changed, 174 insertions(+), 38 deletions(-) --- gregkh-2.6.orig/include/linux/fs.h 2005-05-18 11:16:39.000000000 -0700 +++ gregkh-2.6/include/linux/fs.h 2005-05-18 11:16:51.000000000 -0700 @@ -1657,6 +1657,52 @@ ar->size = n; } +/* + * simple attribute files + * + * These attributes behave similar to those in sysfs: + * + * Writing to an attribute immediately sets a value, an open file can be + * written to multiple times. + * + * Reading from an attribute creates a buffer from the value that might get + * read with multiple read calls. When the attribute has been read + * completely, no further read calls are possible until the file is opened + * again. + * + * All attributes contain a text representation of a numeric value + * that are accessed with the get() and set() functions. + */ +#define DEFINE_SIMPLE_ATTRIBUTE(__fops, __get, __set, __fmt) \ +static int __fops ## _open(struct inode *inode, struct file *file) \ +{ \ + __simple_attr_check_format(__fmt, 0ul); \ + return simple_attr_open(inode, file, &__get, &__set, __fmt); \ +} \ +static struct file_operations __fops = { \ + .owner = THIS_MODULE, \ + .open = __fops ## _open, \ + .release = simple_attr_close, \ + .read = simple_attr_read, \ + .write = simple_attr_write, \ +}; + +static inline void __attribute__((format(printf, 1, 2))) +__simple_attr_check_format(const char *fmt, ...) +{ + /* don't do anything, just let the compiler check the arguments; */ +} + +int simple_attr_open(struct inode *inode, struct file *file, + u64 (*get)(void *), void (*set)(void *, u64), + const char *fmt); +int simple_attr_close(struct inode *inode, struct file *file); +ssize_t simple_attr_read(struct file *file, char __user *buf, + size_t len, loff_t *ppos); +ssize_t simple_attr_write(struct file *file, const char __user *buf, + size_t len, loff_t *ppos); + + #ifdef CONFIG_SECURITY static inline char *alloc_secdata(void) { --- gregkh-2.6.orig/fs/libfs.c 2005-05-18 11:16:39.000000000 -0700 +++ gregkh-2.6/fs/libfs.c 2005-05-18 11:19:09.000000000 -0700 @@ -519,6 +519,101 @@ return 0; } +/* Simple attribute files */ + +struct simple_attr { + u64 (*get)(void *); + void (*set)(void *, u64); + char get_buf[24]; /* enough to store a u64 and "\n\0" */ + char set_buf[24]; + void *data; + const char *fmt; /* format for read operation */ + struct semaphore sem; /* protects access to these buffers */ +}; + +/* simple_attr_open is called by an actual attribute open file operation + * to set the attribute specific access operations. */ +int simple_attr_open(struct inode *inode, struct file *file, + u64 (*get)(void *), void (*set)(void *, u64), + const char *fmt) +{ + struct simple_attr *attr; + + attr = kmalloc(sizeof(*attr), GFP_KERNEL); + if (!attr) + return -ENOMEM; + + attr->get = get; + attr->set = set; + attr->data = inode->u.generic_ip; + attr->fmt = fmt; + init_MUTEX(&attr->sem); + + file->private_data = attr; + + return nonseekable_open(inode, file); +} + +int simple_attr_close(struct inode *inode, struct file *file) +{ + kfree(file->private_data); + return 0; +} + +/* read from the buffer that is filled with the get function */ +ssize_t simple_attr_read(struct file *file, char __user *buf, + size_t len, loff_t *ppos) +{ + struct simple_attr *attr; + size_t size; + ssize_t ret; + + attr = file->private_data; + + if (!attr->get) + return -EACCES; + + down(&attr->sem); + if (*ppos) /* continued read */ + size = strlen(attr->get_buf); + else /* first read */ + size = scnprintf(attr->get_buf, sizeof(attr->get_buf), + attr->fmt, attr->get(attr->data)); + + ret = simple_read_from_buffer(buf, len, ppos, attr->get_buf, size); + up(&attr->sem); + return ret; +} + +/* interpret the buffer as a number to call the set function with */ +ssize_t simple_attr_write(struct file *file, const char __user *buf, + size_t len, loff_t *ppos) +{ + struct simple_attr *attr; + u64 val; + size_t size; + ssize_t ret; + + attr = file->private_data; + + if (!attr->set) + return -EACCES; + + down(&attr->sem); + ret = -EFAULT; + size = min(sizeof(attr->set_buf) - 1, len); + if (copy_from_user(attr->set_buf, buf, size)) + goto out; + + ret = len; /* claim we got the whole input */ + attr->set_buf[size] = '\0'; + val = simple_strtol(attr->set_buf, NULL, 0); + attr->set(attr->data, val); +out: + up(&attr->sem); + return ret; +} + EXPORT_SYMBOL(dcache_dir_close); EXPORT_SYMBOL(dcache_dir_lseek); EXPORT_SYMBOL(dcache_dir_open); @@ -547,3 +642,7 @@ EXPORT_SYMBOL(simple_transaction_get); EXPORT_SYMBOL(simple_transaction_read); EXPORT_SYMBOL(simple_transaction_release); +EXPORT_SYMBOL_GPL(simple_attr_open); +EXPORT_SYMBOL_GPL(simple_attr_close); +EXPORT_SYMBOL_GPL(simple_attr_read); +EXPORT_SYMBOL_GPL(simple_attr_write); --- gregkh-2.6.orig/fs/debugfs/file.c 2005-05-18 11:16:39.000000000 -0700 +++ gregkh-2.6/fs/debugfs/file.c 2005-05-18 11:18:35.000000000 -0700 @@ -45,44 +45,15 @@ .open = default_open, }; -#define simple_type(type, format, temptype, strtolfn) \ -static ssize_t read_file_##type(struct file *file, char __user *user_buf, \ - size_t count, loff_t *ppos) \ -{ \ - char buf[32]; \ - type *val = file->private_data; \ - \ - snprintf(buf, sizeof(buf), format "\n", *val); \ - return simple_read_from_buffer(user_buf, count, ppos, buf, strlen(buf));\ -} \ -static ssize_t write_file_##type(struct file *file, const char __user *user_buf,\ - size_t count, loff_t *ppos) \ -{ \ - char *endp; \ - char buf[32]; \ - int buf_size; \ - type *val = file->private_data; \ - temptype tmp; \ - \ - memset(buf, 0x00, sizeof(buf)); \ - buf_size = min(count, (sizeof(buf)-1)); \ - if (copy_from_user(buf, user_buf, buf_size)) \ - return -EFAULT; \ - \ - tmp = strtolfn(buf, &endp, 0); \ - if ((endp == buf) || ((type)tmp != tmp)) \ - return -EINVAL; \ - *val = tmp; \ - return count; \ -} \ -static struct file_operations fops_##type = { \ - .read = read_file_##type, \ - .write = write_file_##type, \ - .open = default_open, \ -}; -simple_type(u8, "%c", unsigned long, simple_strtoul); -simple_type(u16, "%hi", unsigned long, simple_strtoul); -simple_type(u32, "%i", unsigned long, simple_strtoul); +static void debugfs_u8_set(void *data, u64 val) +{ + *(u8 *)data = val; +} +static u64 debugfs_u8_get(void *data) +{ + return *(u8 *)data; +} +DEFINE_SIMPLE_ATTRIBUTE(fops_u8, debugfs_u8_get, debugfs_u8_set, "%lu\n"); /** * debugfs_create_u8 - create a file in the debugfs filesystem that is used to read and write a unsigned 8 bit value. @@ -116,6 +87,16 @@ } EXPORT_SYMBOL_GPL(debugfs_create_u8); +static void debugfs_u16_set(void *data, u64 val) +{ + *(u16 *)data = val; +} +static u64 debugfs_u16_get(void *data) +{ + return *(u16 *)data; +} +DEFINE_SIMPLE_ATTRIBUTE(fops_u16, debugfs_u16_get, debugfs_u16_set, "%lu\n"); + /** * debugfs_create_u16 - create a file in the debugfs filesystem that is used to read and write a unsigned 8 bit value. * @@ -148,6 +129,16 @@ } EXPORT_SYMBOL_GPL(debugfs_create_u16); +static void debugfs_u32_set(void *data, u64 val) +{ + *(u32 *)data = val; +} +static u64 debugfs_u32_get(void *data) +{ + return *(u32 *)data; +} +DEFINE_SIMPLE_ATTRIBUTE(fops_u32, debugfs_u32_get, debugfs_u32_set, "%lu\n"); + /** * debugfs_create_u32 - create a file in the debugfs filesystem that is used to read and write a unsigned 8 bit value. * ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] libfs: add simple attribute files 2005-05-18 20:24 ` Greg KH @ 2005-05-19 8:29 ` Arnd Bergmann 2005-05-19 9:18 ` 2.4 Kernel threads linux 0 siblings, 1 reply; 42+ messages in thread From: Arnd Bergmann @ 2005-05-19 8:29 UTC (permalink / raw) To: Greg KH Cc: linuxppc64-dev, linux-kernel, Paul Mackerras, Anton Blanchard, Benjamin Herrenschmidt On Middeweken 18 Mai 2005 22:24, Greg KH wrote: > Thanks for the patch. I've cleaned it up a bit (drop the spufs > comments, changed the access check, and made the val be u64, and > exported the symbols and cleaned up the debugfs portion) and added it to > my tree. It should show up in the next -mm release. I've included the > patch below so you can see my > changes. Great, thanks for cleaning up those mistakes. I noticed one small problem with the change from 'long' to 'u64', in that you did not change it in all places. In particular, using "%lu" to print a u64 value will always do the wrong thing on big-endian 32 bit platforms and maybe on some others. Since 'u64' is '%llu' on most platforms but '%lu' on some 64 bit platforms, I'd either do explicit cast to unsigned long long in the printf or use unsigned long long throughout the code. > void foo_set(void *data, long val); and ^^ u64 > long foo_get(void *data); ^^ u64 > +#define DEFINE_SIMPLE_ATTRIBUTE(__fops, __get, __set, __fmt) \ > +static int __fops ## _open(struct inode *inode, struct file *file) \ > +{ \ > + __simple_attr_check_format(__fmt, 0ul); \ ^^^^ 0ull > + else /* first read */ > + size = scnprintf(attr->get_buf, sizeof(attr->get_buf), > + attr->fmt, attr->get(attr->data)); ^^ (unsigned long long) > +DEFINE_SIMPLE_ATTRIBUTE(fops_u8, debugfs_u8_get, debugfs_u8_set, "%lu\n"); > +DEFINE_SIMPLE_ATTRIBUTE(fops_u16, debugfs_u16_get, debugfs_u16_set, "%lu\n"); > +DEFINE_SIMPLE_ATTRIBUTE(fops_u32, debugfs_u32_get, debugfs_u32_set, "%lu\n"); %llu ^^^^ I also noticed that it is not possible to pass NULL operations to DEFINE_SIMPLE_ATTRIBUTE() unless you change --- a/include/linux/fs.h 2005-05-19 10:17:53.000000000 +0200 +++ b/include/linux/fs.h 2005-05-19 10:14:57.000000000 +0200 @@ -1680,7 +1680,7 @@ static int __fops ## _open(struct inode *inode, struct file *file) \ { \ __simple_attr_check_format(__fmt, 0ul); \ - return simple_attr_open(inode, file, &__get, &__set, __fmt); \ + return simple_attr_open(inode, file, __get, __set, __fmt); \ } \ static struct file_operations __fops = { \ .owner = THIS_MODULE, \ I'm currently away from my test machine, so I think it's easier if you just update your patch yourself, but I could also send you an update patch later if you prefer. Arnd <>< ^ permalink raw reply [flat|nested] 42+ messages in thread
* 2.4 Kernel threads 2005-05-19 8:29 ` Arnd Bergmann @ 2005-05-19 9:18 ` linux 0 siblings, 0 replies; 42+ messages in thread From: linux @ 2005-05-19 9:18 UTC (permalink / raw) To: lkml Hi all, i am starting from inside a module a kernel thread*,but in some time later i want to remove that module. What is the process while unloading a module to release a kernel thread in 2.4.x kernel series.????? * kernel_thread(module_thread, &startup, CLONE_KERNEL); Thanks in advance. ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2005-06-24 15:34 UTC | newest] Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-05-18 17:33 [Ocfs2-devel] [RFC] [PATCH] OCFS2 Mark Fasheh 2005-05-18 22:33 ` Mark Fasheh 2005-05-18 19:56 ` [Ocfs2-devel] " Adrian Bunk 2005-05-18 23:40 ` Adrian Bunk 2005-05-18 20:26 ` [Ocfs2-devel] " Manish Singh 2005-05-19 1:26 ` Manish Singh 2005-05-19 4:59 ` Adrian Bunk 2005-05-19 9:45 ` Adrian Bunk 2005-05-19 10:24 ` 2.4 kernel threads linux 2005-05-19 10:39 ` Arjan van de Ven 2005-05-19 16:19 ` Jesse Barnes 2005-05-18 19:56 ` [Ocfs2-devel] Re: [RFC] [PATCH] OCFS2 Hans Reiser 2005-05-18 23:35 ` Hans Reiser 2005-05-18 23:28 ` [Ocfs2-devel] " Kyle Moffett 2005-05-19 2:30 ` Kyle Moffett 2005-05-18 23:30 ` [Ocfs2-devel] " Mark Fasheh 2005-05-19 4:30 ` Mark Fasheh 2005-05-19 1:52 ` [Ocfs2-devel] " Daniel Phillips 2005-05-19 6:30 ` Daniel Phillips 2005-05-19 1:54 ` [Ocfs2-devel] " Mark Fasheh 2005-05-19 6:54 ` Mark Fasheh 2005-05-19 11:19 ` [Ocfs2-devel] " Daniel Phillips 2005-05-19 16:23 ` Daniel Phillips 2005-05-19 10:26 ` Jeff Garzik 2005-05-19 15:09 ` [Ocfs2-devel] " Jeff Garzik 2005-05-19 15:09 ` Lee Revell 2005-05-19 15:20 ` Lee Revell 2005-05-19 15:09 ` [Ocfs2-devel] " Jeff Garzik 2005-05-19 15:25 ` Jeff Garzik 2005-06-23 13:03 ` [Ocfs2-devel] " James Morris 2005-06-23 18:03 ` James Morris 2005-06-23 13:29 ` [Ocfs2-devel] " Mark Fasheh 2005-06-23 18:29 ` Mark Fasheh 2005-06-24 3:05 ` Paul Jackson 2005-06-24 15:34 ` [Ocfs2-devel] " Paul Jackson 2005-06-23 23:00 ` Mark Fasheh 2005-06-24 3:59 ` Mark Fasheh 2005-06-24 4:17 ` Paul Jackson 2005-06-24 15:34 ` [Ocfs2-devel] " Paul Jackson 2005-06-24 3:29 ` Paul Jackson 2005-06-24 15:34 ` [Ocfs2-devel] " Paul Jackson -- strict thread matches above, loose matches on Subject: below -- 2005-05-13 19:31 [PATCH 0/8] ppc64: Introduce Cell/BPA platform, v2 Arnd Bergmann 2005-05-18 12:40 ` [PATCH] libfs: add simple attribute files Arnd Bergmann 2005-05-18 20:24 ` Greg KH 2005-05-19 8:29 ` Arnd Bergmann 2005-05-19 9:18 ` 2.4 Kernel threads linux
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.