Re: CheckFS: Checkpoints and Block Level Incremental Backup (BLIB)
On Monday 25 Jul 2005 6:02 pm, Theodore Ts'o wrote: > On Mon, Jul 25, 2005 at 11:24:43AM +0530, Amit S. Kale wrote: > > On Sunday 24 Jul 2005 8:44 pm, Jan Engelhardt wrote: > > > >Maybe you want to put your development machines on ext*2* while doing > > > >this ;-). Or perhaps reiserfs/xfs/something. > > > > > > Or perhaps into at the VFS level, so any fs can benefit from it. > > > > We thought about that. While it's possible to do that, it would need > > hooks into all filesystems etc. Definitely worth trying once we get > > some more basic stuff working for ext3 > > > > After all the things that need to be saved at the time of taking a > > checkpoint for any filesystem would be the superblock and inode > > table (or their equivalents). Everything else is automatically taken > > care of. > > You are aware of the block-device-level snapshot solutions, right? > They can be more painful to use, although that's mostly a UI issue, > and they have the added advantage that you can safely run e2fsck on > the snapshot image if you want to check the consistency of the > filesystem while it is mounted. That would be a lesser advantage IMHO compared to the advantage of being able to manage disks in a better way. Block-device level snapshots are simple to implement, though making them intelligent is quite difficult. Block device level snapshots can't detect which block are allocated and which are not (unless they look into a filesystem's block allocation map, which requires a device->fs interface). A snapshot may hence require an exhorbitant amount of space when it's not really needed. The BLIB procedure to be used with checkfs is to create a checkpoint. Transfer it to disk as the first full backup. This operation uses the free space available within the filesystem till the time the data is transfered to a tape. A similar procedure used with block-level backup will require an auxilliary device. Generally filesystem level snapshots/checkpoints can be more intelligent hence easier to use and requires fewer resources. -Amit > (If it is clean, you can then use > tune2fs to reset the max-mount-count and last-checked-time on the > original filesystem image; if it is not clean, you can send e-mail to > the system administrator suggesting that she schedule downtime ASAP > and do a e2fsck on the filesystem image. This is a good thing that a > paranoid sysadmin might schedule via cron every Saturday morning at > 3am, for example.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CheckFS: Checkpoints and Block Level Incremental Backup (BLIB)
On Sunday 24 Jul 2005 8:44 pm, Jan Engelhardt wrote: > >Maybe you want to put your development machines on ext*2* while doing > >this ;-). Or perhaps reiserfs/xfs/something. > > Or perhaps into at the VFS level, so any fs can benefit from it. We thought about that. While it's possible to do that, it would need hooks into all filesystems etc. Definitely worth trying once we get some more basic stuff working for ext3 After all the things that need to be saved at the time of taking a checkpoint for any filesystem would be the superblock and inode table (or their equivalents). Everything else is automatically taken care of. -Amit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CheckFS: Checkpoints and Block Level Incremental Backup (BLIB)
On Sunday 24 Jul 2005 8:44 pm, Jan Engelhardt wrote: Maybe you want to put your development machines on ext*2* while doing this ;-). Or perhaps reiserfs/xfs/something. Or perhaps into at the VFS level, so any fs can benefit from it. We thought about that. While it's possible to do that, it would need hooks into all filesystems etc. Definitely worth trying once we get some more basic stuff working for ext3 After all the things that need to be saved at the time of taking a checkpoint for any filesystem would be the superblock and inode table (or their equivalents). Everything else is automatically taken care of. -Amit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CheckFS: Checkpoints and Block Level Incremental Backup (BLIB)
On Monday 25 Jul 2005 6:02 pm, Theodore Ts'o wrote: On Mon, Jul 25, 2005 at 11:24:43AM +0530, Amit S. Kale wrote: On Sunday 24 Jul 2005 8:44 pm, Jan Engelhardt wrote: Maybe you want to put your development machines on ext*2* while doing this ;-). Or perhaps reiserfs/xfs/something. Or perhaps into at the VFS level, so any fs can benefit from it. We thought about that. While it's possible to do that, it would need hooks into all filesystems etc. Definitely worth trying once we get some more basic stuff working for ext3 After all the things that need to be saved at the time of taking a checkpoint for any filesystem would be the superblock and inode table (or their equivalents). Everything else is automatically taken care of. You are aware of the block-device-level snapshot solutions, right? They can be more painful to use, although that's mostly a UI issue, and they have the added advantage that you can safely run e2fsck on the snapshot image if you want to check the consistency of the filesystem while it is mounted. That would be a lesser advantage IMHO compared to the advantage of being able to manage disks in a better way. Block-device level snapshots are simple to implement, though making them intelligent is quite difficult. Block device level snapshots can't detect which block are allocated and which are not (unless they look into a filesystem's block allocation map, which requires a device-fs interface). A snapshot may hence require an exhorbitant amount of space when it's not really needed. The BLIB procedure to be used with checkfs is to create a checkpoint. Transfer it to disk as the first full backup. This operation uses the free space available within the filesystem till the time the data is transfered to a tape. A similar procedure used with block-level backup will require an auxilliary device. Generally filesystem level snapshots/checkpoints can be more intelligent hence easier to use and requires fewer resources. -Amit (If it is clean, you can then use tune2fs to reset the max-mount-count and last-checked-time on the original filesystem image; if it is not clean, you can send e-mail to the system administrator suggesting that she schedule downtime ASAP and do a e2fsck on the filesystem image. This is a good thing that a paranoid sysadmin might schedule via cron every Saturday morning at 3am, for example.) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CheckFS: Checkpoints and Block Level Incremental Backup (BLIB)
Ted, Thanks for your suggestions and help. We started it from 2.6.7 last year and then it was sitting idle for several months for lack of resources. We'll go back to that version and generate a diff that's easier to read. Yes, changing the name has made the task of rebasing wrt. changing kernels lot difficult. Our original intention was to make testing easier by keeping ext3 and checkfs filesystems in the same kernel. Had we continued it at that point, we would have posted differences wrt. ext3 sources themselves. There was compelling reason to change the name. Regards. -Amit > This looks like very interesting technology, but out of curiosity, why > did you develop this as separate filesystem with a new filesystem > name, and doing a global search-and-replace of "ext3" with "checkfs" > in the source files, instead of simply just modifying ext3 and posting > diffs? Especially since that the apparent intention is to keep ext3 > compatibility using the same ext3 magic numbers, data formats, and > user-mode utilities. > > I'll reserve the superblock fields and compatibility bitmap fields > used by your code in e2fsprogs to help avoid the possibility of other > folks working on ext3 extensions from colliding with the codepoints > which you "borrowed", but in the future, it would be good if people > contact me in advance so I ensure that there are no collisions with > other development groups. > > What version of the source base did you originally fork checkfs from? > That way we can do a "s/checkfs/ext3/g" search and replace and then > generate some diffs to see what you changed, or alternatively, it > would be even better if you minimized differences between your version > and mainline and generated the diffs yourself. > > Thanks, regards, > > - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CheckFS: Checkpoints and Block Level Incremental Backup (BLIB)
Ted, Thanks for your suggestions and help. We started it from 2.6.7 last year and then it was sitting idle for several months for lack of resources. We'll go back to that version and generate a diff that's easier to read. Yes, changing the name has made the task of rebasing wrt. changing kernels lot difficult. Our original intention was to make testing easier by keeping ext3 and checkfs filesystems in the same kernel. Had we continued it at that point, we would have posted differences wrt. ext3 sources themselves. There was compelling reason to change the name. Regards. -Amit This looks like very interesting technology, but out of curiosity, why did you develop this as separate filesystem with a new filesystem name, and doing a global search-and-replace of ext3 with checkfs in the source files, instead of simply just modifying ext3 and posting diffs? Especially since that the apparent intention is to keep ext3 compatibility using the same ext3 magic numbers, data formats, and user-mode utilities. I'll reserve the superblock fields and compatibility bitmap fields used by your code in e2fsprogs to help avoid the possibility of other folks working on ext3 extensions from colliding with the codepoints which you borrowed, but in the future, it would be good if people contact me in advance so I ensure that there are no collisions with other development groups. What version of the source base did you originally fork checkfs from? That way we can do a s/checkfs/ext3/g search and replace and then generate some diffs to see what you changed, or alternatively, it would be even better if you minimized differences between your version and mainline and generated the diffs yourself. Thanks, regards, - Ted - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kgdb for 2.4.5 kernels
Hi, Linux kernel source level debugger, kgdb is available for kernel version 2.4.5. It contains the same functionality as kgdb for 2.4.3. Please visit http://kgdb.sourceforge.net/ to download it. Regards. -- Amit S. Kale <[EMAIL PROTECTED]> Linux kernel source level debuggerhttp://kgdb.sourceforge.net/ Translation filesystemhttp://trfs.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kgdb for 2.4.5 kernels
Hi, Linux kernel source level debugger, kgdb is available for kernel version 2.4.5. It contains the same functionality as kgdb for 2.4.3. Please visit http://kgdb.sourceforge.net/ to download it. Regards. -- Amit S. Kale [EMAIL PROTECTED] Linux kernel source level debuggerhttp://kgdb.sourceforge.net/ Translation filesystemhttp://trfs.sourceforge.net/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel Debuggers, KDB or KGDB?
Keith Owens wrote: > > On Wed, 2 May 2001 16:06:15 -0500, > Paul J Albrecht <[EMAIL PROTECTED]> wrote: > >I'd like to know more about your plans to enhance KDB with source level debug > >capability. > > Use a combination of gdb and kdb. kdb to support kernel internals, gdb > to take the kdb output and add source level data. It needs two > machines, one that is running to support gdb, the second machine is > being debugged, with a serial console between them. This is how solaris ksld (kernel source level debugger works). solaris dbx connects to a kernel stub which serves as kadb (solaris assembly level debugger) as well as a debugger stub. > The problem will be stopping gdb from making assumptions about the > machine being debugged. Instead of changing gdb code, use a gdb > wrapper program to intercept user commands and gdb serial protocol and > convert them to kdb commands. I am not sure if kdb provides access to kernel threads in a form that can be conveniently by a wrapper program. Interested people can check whether all features of kgdb (http://kgdb.sourceforge.net/) are available in convenient form in kdb. The logic of holding slave cpus (the cpu in the debugger is the master while others are slaves) is different in kdb and kgdb. Handling of nmi-watchdog too is different. > > >Would you have to boot an unstripped kernel executable whenever you > >wanted to debug? > > Boot, no. But the machine running gdb will need an copy of the > unstripped vmlinux and module objects to get the debug information. Plus all the sources. All this is required by gdb. In theory gdb could do well with just source code and symbol information only, though for lack of a symbol information requesting packet in the gdb remote protocol, gdb can't get symbol information directly from the stub. There is some effort in gdb world to allow a stub to query gdb for symbol information. Probably the reverse can also be added. Need someone good understanding of gdb to do that. It's because of these reasons that kgdb module debugging setup is combersome. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Amit Kale Veritas Software ( http://www.veritas.com ) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel Debuggers, KDB or KGDB?
Keith Owens wrote: On Wed, 2 May 2001 16:06:15 -0500, Paul J Albrecht [EMAIL PROTECTED] wrote: I'd like to know more about your plans to enhance KDB with source level debug capability. Use a combination of gdb and kdb. kdb to support kernel internals, gdb to take the kdb output and add source level data. It needs two machines, one that is running to support gdb, the second machine is being debugged, with a serial console between them. This is how solaris ksld (kernel source level debugger works). solaris dbx connects to a kernel stub which serves as kadb (solaris assembly level debugger) as well as a debugger stub. The problem will be stopping gdb from making assumptions about the machine being debugged. Instead of changing gdb code, use a gdb wrapper program to intercept user commands and gdb serial protocol and convert them to kdb commands. I am not sure if kdb provides access to kernel threads in a form that can be conveniently by a wrapper program. Interested people can check whether all features of kgdb (http://kgdb.sourceforge.net/) are available in convenient form in kdb. The logic of holding slave cpus (the cpu in the debugger is the master while others are slaves) is different in kdb and kgdb. Handling of nmi-watchdog too is different. Would you have to boot an unstripped kernel executable whenever you wanted to debug? Boot, no. But the machine running gdb will need an copy of the unstripped vmlinux and module objects to get the debug information. Plus all the sources. All this is required by gdb. In theory gdb could do well with just source code and symbol information only, though for lack of a symbol information requesting packet in the gdb remote protocol, gdb can't get symbol information directly from the stub. There is some effort in gdb world to allow a stub to query gdb for symbol information. Probably the reverse can also be added. Need someone good understanding of gdb to do that. It's because of these reasons that kgdb module debugging setup is combersome. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Amit Kale Veritas Software ( http://www.veritas.com ) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel Debuggers, KDB or KGDB?
Hi, I mostly agree with Keith. kdb and kgdb have similar capabilities. kgdb can be used to do kdb like assembly level debugging too, though it needs some knowledge of gdb and kgdb internals. You can analyze any problems with either of the debuggers. You'll need to decide which debugger to go for depending on your requirements. I've got many queries asking kgdb capabilities. I guess it's time for a webpage comparing the two debuggers. People who are new to linux kernel and have not used any of the debuggers can hardly arrive at a decision as to which debugger is better suited for their work. I always suggest for kgdb over kdb because, IMO source level debugging makes a programmers life much easier. UML too is a good kernel debugging tool. It offers the advantage of source level debugging on a single machine. IMHO it's more useful for beginners. Keith Owens wrote: > > On Mon, 30 Apr 2001 16:17:22 -0500, > Paul J Albrecht <[EMAIL PROTECTED]> wrote: > >Where can I find an analysis of the relative strengths and weaknesses of KDB > >and KGDB for kernel debug? Has the linux community come to any consensus > >regarding the utility one or the other? > > kdb is a really low level debugger which understands the kernel > structures. It does its utmost to stop all kernel activity while it is > running and to use as few kernel services as possible so it can run > even when the kernel is dead. It (currently) has no source level > debugging. > > kgdb relies on gdb so you loose the knowledge of kernel internals (no, > I am *not* going to teach gdb about kernel stacks, out of line lock > code etc.). kgdb has more of a dependency on a working kernel. It > provides source level debugging, although stack backtrace tends not to > work unless you compile the kernel with frame pointers. > > UML is great for debugging generic kernel code such as filesystems, but > cannot be used for most arch code or hardware drivers. > > My ideal debugger is one that combines the internal knowledge of kdb > with the source level debugging of gdb. I know how to do this over a > serial line, finding time to write the code is the problem. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Amit Kale Veritas Software ( http://www.veritas.com ) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel Debuggers, KDB or KGDB?
Hi, I mostly agree with Keith. kdb and kgdb have similar capabilities. kgdb can be used to do kdb like assembly level debugging too, though it needs some knowledge of gdb and kgdb internals. You can analyze any problems with either of the debuggers. You'll need to decide which debugger to go for depending on your requirements. I've got many queries asking kgdb capabilities. I guess it's time for a webpage comparing the two debuggers. People who are new to linux kernel and have not used any of the debuggers can hardly arrive at a decision as to which debugger is better suited for their work. I always suggest for kgdb over kdb because, IMO source level debugging makes a programmers life much easier. UML too is a good kernel debugging tool. It offers the advantage of source level debugging on a single machine. IMHO it's more useful for beginners. Keith Owens wrote: On Mon, 30 Apr 2001 16:17:22 -0500, Paul J Albrecht [EMAIL PROTECTED] wrote: Where can I find an analysis of the relative strengths and weaknesses of KDB and KGDB for kernel debug? Has the linux community come to any consensus regarding the utility one or the other? kdb is a really low level debugger which understands the kernel structures. It does its utmost to stop all kernel activity while it is running and to use as few kernel services as possible so it can run even when the kernel is dead. It (currently) has no source level debugging. kgdb relies on gdb so you loose the knowledge of kernel internals (no, I am *not* going to teach gdb about kernel stacks, out of line lock code etc.). kgdb has more of a dependency on a working kernel. It provides source level debugging, although stack backtrace tends not to work unless you compile the kernel with frame pointers. UML is great for debugging generic kernel code such as filesystems, but cannot be used for most arch code or hardware drivers. My ideal debugger is one that combines the internal knowledge of kdb with the source level debugging of gdb. I know how to do this over a serial line, finding time to write the code is the problem. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Amit Kale Veritas Software ( http://www.veritas.com ) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to gdbstub++ taking care of possible stale data in Recievebuffers and qOffsets cmd for x86.
Thanks for analyzing a possible scenario where gdb and kgdb could go out of sync. The gdb remote debugging protocol isn't quite safe whenever both gdb and stub try to talk to each other. There are a few other scenarios which occur more frequently. Some gdb developers are trying to make the gdb remote protocol better. Hopefully they should come up with a protocol that does not suffer from such problems. You can look in gdb mailing list archives from http://sources.redhat.com/gdb/ I'll list another unsafe gdb packet on which there was a discussion on gdb mailing list: The kgdb console output uses "O" gdb packet which doesn't have an acknowledgement associated with it. Since the number of console messages can be large at times, this may cause gdb to go out of sync when a user presses Ctrl + C. I have seen this occur, though rarely. Hanish Menon C wrote: > > Hi > > This patch takes care of 2 things related to remote debuging of Linux > kernel using Gdb > > Problem and Solution (1) > > > When trying out Remote Debugging of Linux kernel using GDB, I found a > possible protocol synchronisation issue between gdb (in host) and gdbstub > (on RemoteTarget) in the current gdb remote protocol implementation (i.e > which don't use the SequenceNumber mechanism of the protocol). > > The situation unfolds as follows > 1) HostGdb sends a command to the RemoteTargetStub. > 2) Before the RemoteTargetStub can process the command a exception or > breakpoint occurs. Or the RemoteTargetStub is getting activated only now > during booting of the RemoteTarget m/c. > 3) RemoteTargetStub sends Sxx to HostGDB. HostGDB takes this as response > to command from 1 above (or ignores the command from 1 due to this) > 4) HostGDB sends a new gdb command. > 5) RemoteTargetStub picks up the old gdb command (from 1), and responds > to it. > 6) HostGDB assumes its the response to the new command from 4 above, but > actually its response to the old (now stale or no longer valid) command > from 1 above. > > Thus the RemoteTargetGdbStub and the HostGDB go out of sync. > > I faced this problem when trying out remote debuging between a Linux Host > and a PC Emulation software (vmware or so) using /dev/ptyq0 and /dev/ttyq0 > for communication. On looking into this I found this possible > synchronisation problem between the Host and Remote in GDB protocol, if > there is any content or old command in the Recieve buffers (s/w buffer in > gdbserial.c and or h/w buffer of uart) due to what ever reason. > > To solve this problem I have implemented a clearRecieveDataBufferGDB in > gdbserail which when invoked will clear all buffered contents associated > with recieving ((a) the s/w buffer in gdbserial and (b) the buffer in > uart). It uses the existing read_char implementation of gdbserial in a > loop to accomplish this. > > INTURN I call this from with in handle_exception of gdbstub just before > sending SXX signal(to notify of the exception) to HostGDB, So that > handle_exception won't respond to any old (and no longer valid)command or > invalid data in the Recieve buffer. > > Problem and Solution (2) > > > Also I noticed that HostGDB was sending a qOffsets query to the > RemoteTargetStub, but x86 gdbstub doesn't currently provide a > implementation for qOffset. So I implemented one which uses the following > symbols to provide the required offsets > > stext for Text > gdt_table for Data (currently corresponds to .data or sdata) > __bss_start for Bss. > > However once Implemented I did find that HostGDBs symbol info was getting > corrupted and I was forced to reload the symbols using symbol_file. On > looking into gdb source casualy it felt as if I can ignore qOffsets > command. Either way I already had a implementation (which is very > simple) for qOffsets command, so I have retained it in the patch __as the > bug__ seems to be __in the HostGDB code__. On looking into other gdbstub > implementations in the linux kernel Even the PPC arch's gdbstub talks > about this bug in HostGDB. > > Also I picked up the elegent sprintf solution to create the response > string for qOffset from the PPC guys. Earlier I had tried a solution with > mem2hex which retains the Bytes of the address in the Target Byte order, > but for qOffset one requires to represent the address (in Hex) in the > normal reading order (varified by looking into remote.c in gdb > source) which automaticaly suites the sprintf solution. > > These problem seems to be universal as far as gdb remote debug protocols > current implementations are concerned, so may be even the GDB guys need to > be informed about these possible problems. But I am not in the GDB devel > list, so someone on the list can inform them also. > > --- > Keep :-) > HanishKVC > > > Name:
Re: Patch to gdbstub++ taking care of possible stale data in Recievebuffers and qOffsets cmd for x86.
Thanks for analyzing a possible scenario where gdb and kgdb could go out of sync. The gdb remote debugging protocol isn't quite safe whenever both gdb and stub try to talk to each other. There are a few other scenarios which occur more frequently. Some gdb developers are trying to make the gdb remote protocol better. Hopefully they should come up with a protocol that does not suffer from such problems. You can look in gdb mailing list archives from http://sources.redhat.com/gdb/ I'll list another unsafe gdb packet on which there was a discussion on gdb mailing list: The kgdb console output uses O gdb packet which doesn't have an acknowledgement associated with it. Since the number of console messages can be large at times, this may cause gdb to go out of sync when a user presses Ctrl + C. I have seen this occur, though rarely. Hanish Menon C wrote: Hi This patch takes care of 2 things related to remote debuging of Linux kernel using Gdb Problem and Solution (1) When trying out Remote Debugging of Linux kernel using GDB, I found a possible protocol synchronisation issue between gdb (in host) and gdbstub (on RemoteTarget) in the current gdb remote protocol implementation (i.e which don't use the SequenceNumber mechanism of the protocol). The situation unfolds as follows 1) HostGdb sends a command to the RemoteTargetStub. 2) Before the RemoteTargetStub can process the command a exception or breakpoint occurs. Or the RemoteTargetStub is getting activated only now during booting of the RemoteTarget m/c. 3) RemoteTargetStub sends Sxx to HostGDB. HostGDB takes this as response to command from 1 above (or ignores the command from 1 due to this) 4) HostGDB sends a new gdb command. 5) RemoteTargetStub picks up the old gdb command (from 1), and responds to it. 6) HostGDB assumes its the response to the new command from 4 above, but actually its response to the old (now stale or no longer valid) command from 1 above. Thus the RemoteTargetGdbStub and the HostGDB go out of sync. I faced this problem when trying out remote debuging between a Linux Host and a PC Emulation software (vmware or so) using /dev/ptyq0 and /dev/ttyq0 for communication. On looking into this I found this possible synchronisation problem between the Host and Remote in GDB protocol, if there is any content or old command in the Recieve buffers (s/w buffer in gdbserial.c and or h/w buffer of uart) due to what ever reason. To solve this problem I have implemented a clearRecieveDataBufferGDB in gdbserail which when invoked will clear all buffered contents associated with recieving ((a) the s/w buffer in gdbserial and (b) the buffer in uart). It uses the existing read_char implementation of gdbserial in a loop to accomplish this. INTURN I call this from with in handle_exception of gdbstub just before sending SXX signal(to notify of the exception) to HostGDB, So that handle_exception won't respond to any old (and no longer valid)command or invalid data in the Recieve buffer. Problem and Solution (2) Also I noticed that HostGDB was sending a qOffsets query to the RemoteTargetStub, but x86 gdbstub doesn't currently provide a implementation for qOffset. So I implemented one which uses the following symbols to provide the required offsets stext for Text gdt_table for Data (currently corresponds to .data or sdata) __bss_start for Bss. However once Implemented I did find that HostGDBs symbol info was getting corrupted and I was forced to reload the symbols using symbol_file. On looking into gdb source casualy it felt as if I can ignore qOffsets command. Either way I already had a implementation (which is very simple) for qOffsets command, so I have retained it in the patch __as the bug__ seems to be __in the HostGDB code__. On looking into other gdbstub implementations in the linux kernel Even the PPC arch's gdbstub talks about this bug in HostGDB. Also I picked up the elegent sprintf solution to create the response string for qOffset from the PPC guys. Earlier I had tried a solution with mem2hex which retains the Bytes of the address in the Target Byte order, but for qOffset one requires to represent the address (in Hex) in the normal reading order (varified by looking into remote.c in gdb source) which automaticaly suites the sprintf solution. These problem seems to be universal as far as gdb remote debug protocols current implementations are concerned, so may be even the GDB guys need to be informed about these possible problems. But I am not in the GDB devel list, so someone on the list can inform them also. --- Keep :-) HanishKVC Name: linux-2.4.3-kgdb-hankvc-30Apr2001-p1.patch linux-2.4.3-kgdb-hankvc-30Apr2001-p1.patchType: Plain Text (TEXT/PLAIN)
kgdb for 2.4.3 kernels
Hi, OOPS! I sent a wrong mail earlier under the same subject. Linux kernel source level debugger, kgdb for linux kernel 2.4.3 is available from http://kgdb.sourceforge.net/ This version has following improvements over kgdb for 2.4.2 kernels: 1. Changed #ifdef __SMP__ statements to #ifdef CONFIG_SMP. 2. Removed EXTRAVERSION=-kgdb line from the Makefile. This had caused change in the name of the kernel. It was inconvenient in some setups. If name of the kernel was already changed, the patch would fail at this line. Regards. -- Amit S. Kale <[EMAIL PROTECTED]> Linux kernel source level debuggerhttp://kgdb.sourceforge.net/ Translation filesystemhttp://trfs.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kgdb for 2.4.3 kernels
Hi, Here is another way of allowing sane access to file system specific information, statistics and configuration. It involves using the translation filesystem (http://trfs.sourceforge.net/). An example of filesystem configuration: configurable forcing data flush for all writes to files in a filesystem, is implemented and is available for download. It is implemented for ext2tr filesystem, which is ext2 filesystem with few modifications to use the translation filesystem. Filesystem views Filesystem views give information about filesystems and allow users to configure them. Filesystem views for files and directories residing in the same filesystem are identical. They are applicable to the whole filesystem. An example filesystem view fs/config has been provided for ext2tr filesytem. This view can be used to configure the filesystem to immediately flush data written to files in the filesystem. Uses of filesystem views --- Filesystems can allow users to configure them through filesystem configuration views. Although ioctls can be used for the same purpose, using views is better. A comparison of ioctls and translation filesystem views is given on the translation filesystem webpage. A View that gives information for a filesystem can be put into the fs view at fs/info. The view can be instantiated into a directory which contains text files giving filesystem information. Filesystem statistics can be put into fs/stats. fs/config view can be used to configure a filesystem. Example of fs/config view - The ext2tr filesystem (available from downloads page) contains an example translator for fs/config view. The view instantiates into a directory, which contains a file forcedsync. This file is used to control data sync behavior for an ext2tr filesystem. If forcedsync file contains a character 0, flags specified while opening a file in the filesystem are used to determine whether data written to the file is immediately flushed to disk. If forcedsync file contains a character 1, all data written to a file in the filesystem is immediately flushed to disk regardless of the flags specified while opening the file. Contents of the file can be checked by reading it and can be changed by writing to it. A usage of the view is shown below. In the example, dd command required 0.10 seconds when forcedsync was not enabled. After enabling forcedsync, dd command required 1.62 seconds because data was being flushed at each write system call. [root@localhost /root]# mkfs -t ext2 /dev/hda5 > /dev/null mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 [root@localhost /root]# mount -t ext2tr /dev/hda5 /mnt0 [root@localhost /root]# time dd if=/dev/zero of=/mnt0/foo bs=1024 count=100 100+0 records in 100+0 records out 0.00user 0.02system 0:00.10elapsed 18%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (116major+20minor)pagefaults 0swaps [root@localhost /root]# umount /mnt0 [root@localhost /root]# mkfs -t ext2 /dev/hda5 > /dev/null mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 [root@localhost /root]# mount -t ext2tr /dev/hda5 /mnt0 [root@localhost /root]# /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0 fs/config -c ls @1/ forcedsync [root@localhost /root]# /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0 fs/config -c cat @1/forcedsync [root@localhost /root]# echo 1 | /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0 fs/config -c dd of=@1/forcedsync bs=1 count=1 1+0 records in 1+0 records out [root@localhost /root]# /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0 fs/config -c cat @1/forcedsync [root@localhost /root]# time dd if=/dev/zero of=/mnt0/foo bs=1024 count=100 100+0 records in 100+0 records out 0.00user 0.01system 0:01.62elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (116major+20minor)pagefaults 0swaps -- Amit S. Kale <[EMAIL PROTECTED]> Linux kernel source level debugger http://kgdb.sourceforge.net/ Translation Filesystem http://trfs.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kgdb for 2.4.3 kernels
Hi, Here is another way of allowing sane access to file system specific information, statistics and configuration. It involves using the translation filesystem (http://trfs.sourceforge.net/). An example of filesystem configuration: configurable forcing data flush for all writes to files in a filesystem, is implemented and is available for download. It is implemented for ext2tr filesystem, which is ext2 filesystem with few modifications to use the translation filesystem. Filesystem views Filesystem views give information about filesystems and allow users to configure them. Filesystem views for files and directories residing in the same filesystem are identical. They are applicable to the whole filesystem. An example filesystem view fs/config has been provided for ext2tr filesytem. This view can be used to configure the filesystem to immediately flush data written to files in the filesystem. Uses of filesystem views --- Filesystems can allow users to configure them through filesystem configuration views. Although ioctls can be used for the same purpose, using views is better. A comparison of ioctls and translation filesystem views is given on the translation filesystem webpage. A View that gives information for a filesystem can be put into the fs view at fs/info. The view can be instantiated into a directory which contains text files giving filesystem information. Filesystem statistics can be put into fs/stats. fs/config view can be used to configure a filesystem. Example of fs/config view - The ext2tr filesystem (available from downloads page) contains an example translator for fs/config view. The view instantiates into a directory, which contains a file forcedsync. This file is used to control data sync behavior for an ext2tr filesystem. If forcedsync file contains a character 0, flags specified while opening a file in the filesystem are used to determine whether data written to the file is immediately flushed to disk. If forcedsync file contains a character 1, all data written to a file in the filesystem is immediately flushed to disk regardless of the flags specified while opening the file. Contents of the file can be checked by reading it and can be changed by writing to it. A usage of the view is shown below. In the example, dd command required 0.10 seconds when forcedsync was not enabled. After enabling forcedsync, dd command required 1.62 seconds because data was being flushed at each write system call. [root@localhost /root]# mkfs -t ext2 /dev/hda5 /dev/null mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 [root@localhost /root]# mount -t ext2tr /dev/hda5 /mnt0 [root@localhost /root]# time dd if=/dev/zero of=/mnt0/foo bs=1024 count=100 100+0 records in 100+0 records out 0.00user 0.02system 0:00.10elapsed 18%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (116major+20minor)pagefaults 0swaps [root@localhost /root]# umount /mnt0 [root@localhost /root]# mkfs -t ext2 /dev/hda5 /dev/null mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 [root@localhost /root]# mount -t ext2tr /dev/hda5 /mnt0 [root@localhost /root]# /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0 fs/config -c ls @1/ forcedsync [root@localhost /root]# /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0 fs/config -c cat @1/forcedsync [root@localhost /root]# echo 1 | /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0 fs/config -c dd of=@1/forcedsync bs=1 count=1 1+0 records in 1+0 records out [root@localhost /root]# /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0 fs/config -c cat @1/forcedsync [root@localhost /root]# time dd if=/dev/zero of=/mnt0/foo bs=1024 count=100 100+0 records in 100+0 records out 0.00user 0.01system 0:01.62elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (116major+20minor)pagefaults 0swaps -- Amit S. Kale [EMAIL PROTECTED] Linux kernel source level debugger http://kgdb.sourceforge.net/ Translation Filesystem http://trfs.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Using trfs to configure a filesystem (was Re: [RFC] sane access to per-fs metadata)
Hi, Here is another way of allowing sane access to file system specific information, statistics and configuration. It involves using the translation filesystem (http://trfs.sourceforge.net/). An example of filesystem configuration: configurable forcing data flush for all writes to files in a filesystem, is implemented and is available for download. It is implemented for ext2tr filesystem, which is ext2 filesystem with few modifications to use the translation filesystem. Filesystem views Filesystem views give information about filesystems and allow users to configure them. Filesystem views for files and directories residing in the same filesystem are identical. They are applicable to the whole filesystem. An example filesystem view fs/config has been provided for ext2tr filesytem. This view can be used to configure the filesystem to immediately flush data written to files in the filesystem. Uses of filesystem views --- Filesystems can allow users to configure them through filesystem configuration views. Although ioctls can be used for the same purpose, using views is better. A comparison of ioctls and translation filesystem views is given on the translation filesystem webpage. A View that gives information for a filesystem can be put into the fs view at fs/info. The view can be instantiated into a directory which contains text files giving filesystem information. Filesystem statistics can be put into fs/stats. fs/config view can be used to configure a filesystem. Example of fs/config view - The ext2tr filesystem (available from downloads page) contains an example translator for fs/config view. The view instantiates into a directory, which contains a file forcedsync. This file is used to control data sync behavior for an ext2tr filesystem. If forcedsync file contains a character 0, flags specified while opening a file in the filesystem are used to determine whether data written to the file is immediately flushed to disk. If forcedsync file contains a character 1, all data written to a file in the filesystem is immediately flushed to disk regardless of the flags specified while opening the file. Contents of the file can be checked by reading it and can be changed by writing to it. A usage of the view is shown below. In the example, dd command required 0.10 seconds when forcedsync was not enabled. After enabling forcedsync, dd command required 1.62 seconds because data was being flushed at each write system call. [root@localhost /root]# mkfs -t ext2 /dev/hda5 > /dev/null mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 [root@localhost /root]# mount -t ext2tr /dev/hda5 /mnt0 [root@localhost /root]# time dd if=/dev/zero of=/mnt0/foo bs=1024 count=100 100+0 records in 100+0 records out 0.00user 0.02system 0:00.10elapsed 18%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (116major+20minor)pagefaults 0swaps [root@localhost /root]# umount /mnt0 [root@localhost /root]# mkfs -t ext2 /dev/hda5 > /dev/null mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 [root@localhost /root]# mount -t ext2tr /dev/hda5 /mnt0 [root@localhost /root]# /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0 fs/config -c ls @1/ forcedsync [root@localhost /root]# /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0 fs/config -c cat @1/forcedsync [root@localhost /root]# echo 1 | /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0 fs/config -c dd of=@1/forcedsync bs=1 count=1 1+0 records in 1+0 records out [root@localhost /root]# /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0 fs/config -c cat @1/forcedsync [root@localhost /root]# time dd if=/dev/zero of=/mnt0/foo bs=1024 count=100 100+0 records in 100+0 records out 0.00user 0.01system 0:01.62elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (116major+20minor)pagefaults 0swaps -- Amit S. Kale <[EMAIL PROTECTED]> Linux kernel source level debugger http://kgdb.sourceforge.net/ Translation Filesystem http://trfs.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Using trfs to configure a filesystem (was Re: [RFC] sane access to per-fs metadata)
Hi, Here is another way of allowing sane access to file system specific information, statistics and configuration. It involves using the translation filesystem (http://trfs.sourceforge.net/). An example of filesystem configuration: configurable forcing data flush for all writes to files in a filesystem, is implemented and is available for download. It is implemented for ext2tr filesystem, which is ext2 filesystem with few modifications to use the translation filesystem. Filesystem views Filesystem views give information about filesystems and allow users to configure them. Filesystem views for files and directories residing in the same filesystem are identical. They are applicable to the whole filesystem. An example filesystem view fs/config has been provided for ext2tr filesytem. This view can be used to configure the filesystem to immediately flush data written to files in the filesystem. Uses of filesystem views --- Filesystems can allow users to configure them through filesystem configuration views. Although ioctls can be used for the same purpose, using views is better. A comparison of ioctls and translation filesystem views is given on the translation filesystem webpage. A View that gives information for a filesystem can be put into the fs view at fs/info. The view can be instantiated into a directory which contains text files giving filesystem information. Filesystem statistics can be put into fs/stats. fs/config view can be used to configure a filesystem. Example of fs/config view - The ext2tr filesystem (available from downloads page) contains an example translator for fs/config view. The view instantiates into a directory, which contains a file forcedsync. This file is used to control data sync behavior for an ext2tr filesystem. If forcedsync file contains a character 0, flags specified while opening a file in the filesystem are used to determine whether data written to the file is immediately flushed to disk. If forcedsync file contains a character 1, all data written to a file in the filesystem is immediately flushed to disk regardless of the flags specified while opening the file. Contents of the file can be checked by reading it and can be changed by writing to it. A usage of the view is shown below. In the example, dd command required 0.10 seconds when forcedsync was not enabled. After enabling forcedsync, dd command required 1.62 seconds because data was being flushed at each write system call. [root@localhost /root]# mkfs -t ext2 /dev/hda5 /dev/null mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 [root@localhost /root]# mount -t ext2tr /dev/hda5 /mnt0 [root@localhost /root]# time dd if=/dev/zero of=/mnt0/foo bs=1024 count=100 100+0 records in 100+0 records out 0.00user 0.02system 0:00.10elapsed 18%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (116major+20minor)pagefaults 0swaps [root@localhost /root]# umount /mnt0 [root@localhost /root]# mkfs -t ext2 /dev/hda5 /dev/null mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 [root@localhost /root]# mount -t ext2tr /dev/hda5 /mnt0 [root@localhost /root]# /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0 fs/config -c ls @1/ forcedsync [root@localhost /root]# /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0 fs/config -c cat @1/forcedsync [root@localhost /root]# echo 1 | /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0 fs/config -c dd of=@1/forcedsync bs=1 count=1 1+0 records in 1+0 records out [root@localhost /root]# /home/amit/developement/trfs/cmds/vcmd/vcmd /mnt0 fs/config -c cat @1/forcedsync [root@localhost /root]# time dd if=/dev/zero of=/mnt0/foo bs=1024 count=100 100+0 records in 100+0 records out 0.00user 0.01system 0:01.62elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (116major+20minor)pagefaults 0swaps -- Amit S. Kale [EMAIL PROTECTED] Linux kernel source level debugger http://kgdb.sourceforge.net/ Translation Filesystem http://trfs.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Per user private directories - trfs
Hi, Translators for providing per user private directories and restricting visibility of files and directories using the translation filesystem are available now at http://trfs.sourceforge.net/ Per user private directories: Files created in a per user private directory are not visible to users other than the owner of the files. Per user view enables users to use shared directories as if they were private. Using a peruser view for a shared directory like /tmp allows users to have their own copy of the directory. It also helps reduce contention for directories like /var/spool/mail that undergo a large number of file creations and removals. Restricted visibility of files and directories: Owner of a file can make it invisible to group (of the file) or others by restricting its visibility. A directory listing by a user shows only those files which are visibile to the user. Invisible files cannot be accessed even by using a stat system call. -- Amit S. Kale <[EMAIL PROTECTED]> Linux kernel source level debuggerhttp://kgdb.sourceforge.net/ Translation filesystemhttp://trfs.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Per user private directories - trfs
Hi, Translators for providing per user private directories and restricting visibility of files and directories using the translation filesystem are available now at http://trfs.sourceforge.net/ Per user private directories: Files created in a per user private directory are not visible to users other than the owner of the files. Per user view enables users to use shared directories as if they were private. Using a peruser view for a shared directory like /tmp allows users to have their own copy of the directory. It also helps reduce contention for directories like /var/spool/mail that undergo a large number of file creations and removals. Restricted visibility of files and directories: Owner of a file can make it invisible to group (of the file) or others by restricting its visibility. A directory listing by a user shows only those files which are visibile to the user. Invisible files cannot be accessed even by using a stat system call. -- Amit S. Kale [EMAIL PROTECTED] Linux kernel source level debuggerhttp://kgdb.sourceforge.net/ Translation filesystemhttp://trfs.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kgdb (kernel source level debugger) for 2.4 kernels
Hi, kgdb, kernel source level debugger for x86 linux is available now. Please visit http://kgdb.sourceforge.net/ for downloading. http://kgdb.sourceforge.net/linux-2.4.2-kgdb.patch is the debugger patch for 2.4.2 linux kernel. This version of kgdb has much better support for threads and nmi watchdog. Correct register contents for all threads can be seen now. nmi watchdog is also handled correctly without hangs. Unlike previous version, status of threads running on other cpus is reported correctly in case of nmi watchdog occurrance. Thanks to Dave Grothe for helping me in improving nmi watchdog support. Regards. Amit S. Kale ([EMAIL PROTECTED]) Linux kernel source level debugger http://kgdb.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kgdb (kernel source level debugger) for 2.4 kernels
Hi, kgdb, kernel source level debugger for x86 linux is available now. Please visit http://kgdb.sourceforge.net/ for downloading. http://kgdb.sourceforge.net/linux-2.4.2-kgdb.patch is the debugger patch for 2.4.2 linux kernel. This version of kgdb has much better support for threads and nmi watchdog. Correct register contents for all threads can be seen now. nmi watchdog is also handled correctly without hangs. Unlike previous version, status of threads running on other cpus is reported correctly in case of nmi watchdog occurrance. Thanks to Dave Grothe for helping me in improving nmi watchdog support. Regards. Amit S. Kale ([EMAIL PROTECTED]) Linux kernel source level debugger http://kgdb.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Translation Filesystem
Hi, I have started a new virtual filesystem project, Translation Filesystem at http://trfs.sourceforge.net/ Description of the project is given below. It's still at a concept stage. If someone has any ideas about any useful translators that fit in this framework please write to me. Any feedback is most welcome. Regards. -- Amit Kale Veritas Software ( http://www.veritas.com ) Translation Filesystem The translation filesystem provides views for files. A view offered by the translation filesystem is different from the view offered by a filesystem which contains a file. For example a filesystem presents a tar file as a flat byte stream and the translation filesystem presents it as a directory containing files contained in the tar file. The translation filesystem is based on translators each of which is responsible for creating views for filesystem objects of some type. Root of a translation filesystem contains translator directories. A translator creates views in its directory. A view for a file (or a directory) is generated by creating a symbolic link in a translator directory. The link points to the file for which the view is created. A view is destroyed by removing the symbolic link presenting the view. Properties of a view presented by a symbolic link are determined by the translator which owns the directory in which the link is present. When the symbolic is accessed using stat or open, it presents properties determined by the view. When destination of the symbolic link is read using readlink, it points to the file for which the symbolic link presents a view. The translation filesystem provides views to files contained in a filesytem without the need for modifying the filesystem itself. It does not need extensions to existing filesystems. Since it does not use mount operation for creating a view, users don't need special permissions to create views. It does not use ioctls. So special programs are not needed for configuring a translation filesystem. The file for which a view has been created can be readily identified by reading destination a symbolic link. .At present only one translator, raw, is provided. It provides zero copy read for a block device. Example of Usage [root@localhost /root]# insmod ./trfs [root@localhost /root]# mount none /mnt0 -t trfs [root@localhost /root]# ls /mnt0 [root@localhost /root]# ls /mnt0/raw [root@localhost /root]# ls /mnt0 raw [root@localhost /root]# ln -s /dev/hda1 /mnt0/raw/food [root@localhost /root]# ls /mnt0/raw/food /mnt0/raw/food [root@localhost /root]# dd if=mnt0/raw/food bs=1024 count=1 | hexdump -n 128 000 3ceb 4d90 5753 4e49 2e34 0031 1002 0001 ... [root@localhost /root]# rm /mnt0/raw/food rm: remove `/mnt0/raw/food'? y [root@localhost /root]# ls /mnt0/raw [root@localhost /root]# umount /mnt0 [root@localhost /root]# rmmod trfs [root@localhost /root]# - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Translation Filesystem
Hi, I have started a new virtual filesystem project, Translation Filesystem at http://trfs.sourceforge.net/ Description of the project is given below. It's still at a concept stage. If someone has any ideas about any useful translators that fit in this framework please write to me. Any feedback is most welcome. Regards. -- Amit Kale Veritas Software ( http://www.veritas.com ) Translation Filesystem The translation filesystem provides views for files. A view offered by the translation filesystem is different from the view offered by a filesystem which contains a file. For example a filesystem presents a tar file as a flat byte stream and the translation filesystem presents it as a directory containing files contained in the tar file. The translation filesystem is based on translators each of which is responsible for creating views for filesystem objects of some type. Root of a translation filesystem contains translator directories. A translator creates views in its directory. A view for a file (or a directory) is generated by creating a symbolic link in a translator directory. The link points to the file for which the view is created. A view is destroyed by removing the symbolic link presenting the view. Properties of a view presented by a symbolic link are determined by the translator which owns the directory in which the link is present. When the symbolic is accessed using stat or open, it presents properties determined by the view. When destination of the symbolic link is read using readlink, it points to the file for which the symbolic link presents a view. The translation filesystem provides views to files contained in a filesytem without the need for modifying the filesystem itself. It does not need extensions to existing filesystems. Since it does not use mount operation for creating a view, users don't need special permissions to create views. It does not use ioctls. So special programs are not needed for configuring a translation filesystem. The file for which a view has been created can be readily identified by reading destination a symbolic link. .At present only one translator, raw, is provided. It provides zero copy read for a block device. Example of Usage [root@localhost /root]# insmod ./trfs [root@localhost /root]# mount none /mnt0 -t trfs [root@localhost /root]# ls /mnt0 [root@localhost /root]# ls /mnt0/raw [root@localhost /root]# ls /mnt0 raw [root@localhost /root]# ln -s /dev/hda1 /mnt0/raw/food [root@localhost /root]# ls /mnt0/raw/food /mnt0/raw/food [root@localhost /root]# dd if=mnt0/raw/food bs=1024 count=1 | hexdump -n 128 000 3ceb 4d90 5753 4e49 2e34 0031 1002 0001 ... [root@localhost /root]# rm /mnt0/raw/food rm: remove `/mnt0/raw/food'? y [root@localhost /root]# ls /mnt0/raw [root@localhost /root]# umount /mnt0 [root@localhost /root]# rmmod trfs [root@localhost /root]# - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
kgdb (kernel debugger) updates
Hi, kgdb (patch for using gdb to do source level debugging for linux kernel) is available for 2.4.0-test9 and now supports console output in gdb. Thanks to Duane Voth, it's now available for 2.2.17 kernel also (all features except for console output). Please see http://kgdb.sourceforge.net/ for updates. -- Amit Kale Veritas Software ( http://www.veritas.com ) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
