headers
sniper | 1 Jan 07:05
Picon

HowTo about debugging tux3 with qemu and gdb

The following is the HowTo about debugging tux3 with qemu and gdb.
But it requires two nodes hda and hdb in /dev, I advice you to
repost the filesystem with pre-created these nodes.

cd /dev
mknode -m 644 hda b 3 0
mknode -m 644 hdb b 3 64

And it also requires commenting the following line in file /etc/inittab
#1:23:respawn:/sbin/getty 38400 tty1

HowTo about debugging tux3 with qemu and gdb:

   # Get a kernel tree:
   wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.26.5.tar.bz2
   tar -xjf linux-2.6.26.5.tar.bz2
   cd linux-2.6.26.5

   # Get the Christmas tux3 patch and patch the kernel:
   wget http://tux3.org/patches/tux3-2.6.26.5-4
   patch <tux3-2.6.26.5-4 -p1

   # Build kernel with tux3:
   make defconfig
   make CONFIG_TUX3=y CONFIG_DEBUG_INFO=y CONFIG_FRAME_POINTER=y
   sudo make

   # Get the Christmas tux3 userspace snapshot:
   wget http://tux3.org/downloads/snapshots/tux3-20081230.tar.gz
   tar -xzf tux3-20081230.tar.gz
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Phillips | 1 Jan 10:56

Re: [Tux3] Tux3 report: A Golden Copy

On Wednesday 31 December 2008 10:14, sniper wrote:
> Sorry I meet another problem. After the system was completely setupped,
> the gdb interface will be covered with that system interaction interface.
> So, I can't stop the system's running and add some new break point etc.
> But I can do those operations in remote kgdb debugging.
> 
> Any method to fix this problem?
> 
> Thanks.

I haven't figured that one out.  Usually I get into gdb from uml by
setting a breakpoint, fielding a crash, or executing an explicit
breakpoint: asm("int3").  But I have been unsuccessful so far in
breaking a running uml into the debugger from outside, ever since
SKAS arrived.

Regards,

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Daniel Phillips | 1 Jan 15:25

Re: HowTo about debugging tux3 with qemu and gdb

On Wednesday 31 December 2008 22:05, sniper wrote:
> The following is the HowTo about debugging tux3 with qemu and gdb.
> But it requires two nodes hda and hdb in /dev, I advice you to
> repost the filesystem with pre-created these nodes.
> 
> cd /dev
> mknode -m 644 hda b 3 0
> mknode -m 644 hdb b 3 64
> 
> And it also requires commenting the following line in file /etc/inittab
> #1:23:respawn:/sbin/getty 38400 tty1

Thankyou, I will take care of it pretty soon.

Regards,

Daniel
Permalink | Reply | 0 comments |
headers
Daniel Phillips | 1 Jan 15:46

Re: [Tux3] Tux3 report: A Golden Copy

On Thursday 01 January 2009 01:56, Daniel Phillips wrote:
> On Wednesday 31 December 2008 10:14, sniper wrote:
> > Sorry I meet another problem. After the system was completely setupped,
> > the gdb interface will be covered with that system interaction interface.
> > So, I can't stop the system's running and add some new break point etc.
> > But I can do those operations in remote kgdb debugging.
> > 
> > Any method to fix this problem?
> > 
> > Thanks.
> 
> I haven't figured that one out...

...and now I have.  From Jeff's docs:

   debian package: user-mode-linux-doc
   file:///usr/share/doc/user-mode-linux-doc/html/debugging-skas.html

   "If you need to interrupt UML, you can't ^C it because the terminal
   is in raw mode, and the ^C will just hit whatever UML is running.
   What you need to do is send the UML kernel thread a SIGINT from
   another shell. It is normally the first process after the gdb"

I take no responsibility for the following command:

   kill -INT $(pgrep linux | head -n1)

Regards,

Daniel
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Chinner | 2 Jan 00:58
Favicon

Re: [Tux3] Tux3 report: A Golden Copy

On Thu, Jan 01, 2009 at 02:14:35AM +0800, sniper wrote:
> Sorry I meet another problem. After the system was completely setupped,
> the gdb interface will be covered with that system interaction interface.
> So, I can't stop the system's running and add some new break point etc.
> But I can do those operations in remote kgdb debugging.
> 
> Any method to fix this problem?

Start up the uml console and send an "int" to the UML process.
That should drop it into the debugger. If that doesn't work,
pick the UML process that is burning CPU and send it a SIGTRAP ;)

Cheers,

Dave.
--

-- 
Dave Chinner
david <at> fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Martin Steigerwald | 2 Jan 21:17
Picon

Re: [Tux3] Tux3 report: A Golden Copy

Am Mittwoch 31 Dezember 2008 schrieb Justin P. Mattock:
> Martin Steigerwald wrote:
> > Am Mittwoch 31 Dezember 2008 schrieb Justin P. Mattock:
> >> Daniel Phillips wrote:
> >>> On Tuesday 30 December 2008 23:34, sniper wrote:
> >>>> Great, I have mounted tux3 filesystem under UML with stuffs in
> >>>> this mail, but I still can't debug it with gdb. Anyone gives me
> >>>> suggestion?
> >>>
> >>> You just have to give a "cont" command a bunch of times and you
> >>> will eventually get to a command prompt.  The reason for this is,
> >>> uml uses the segfault interrupt as part of its machine simulation,
> >>> and there is no exsiting way for uml and gdb to communicate in such
> >>> a way that uml can recognize that the interrupt came from its own
> >>> code and filter it.
> >
> > [...]
> >
> >> Hmm.. seems like a redundancy;
> >> Anyways I looked at you're site, but am still
> >> confused at what tux3 is: what is tux3?
> >>
> >> (at first I thought it was  a  video game, but was wrong);
> >> can I use tux3 to secure a linux system or is it for
> >> something else?
> >
> > Hmmm, I thought
> >
> > ---------------------------------------------------------------------
> > Tux3 is a write-anywhere, atomic commit, btree-based versioning
(Continue reading)

Permalink | Reply | 43 comments |
headers
Justin P. Mattock | 2 Jan 21:36
Picon

Re: Tux3 report: A Golden Copy

Martin Steigerwald wrote:
> Am Mittwoch 31 Dezember 2008 schrieb Justin P. Mattock:
>   
>> Martin Steigerwald wrote:
>>     
>>> Am Mittwoch 31 Dezember 2008 schrieb Justin P. Mattock:
>>>       
>>>> Daniel Phillips wrote:
>>>>         
>>>>> On Tuesday 30 December 2008 23:34, sniper wrote:
>>>>>           
>>>>>> Great, I have mounted tux3 filesystem under UML with stuffs in
>>>>>> this mail, but I still can't debug it with gdb. Anyone gives me
>>>>>> suggestion?
>>>>>>             
>>>>> You just have to give a "cont" command a bunch of times and you
>>>>> will eventually get to a command prompt.  The reason for this is,
>>>>> uml uses the segfault interrupt as part of its machine simulation,
>>>>> and there is no exsiting way for uml and gdb to communicate in such
>>>>> a way that uml can recognize that the interrupt came from its own
>>>>> code and filter it.
>>>>>           
>>> [...]
>>>
>>>       
>>>> Hmm.. seems like a redundancy;
>>>> Anyways I looked at you're site, but am still
>>>> confused at what tux3 is: what is tux3?
>>>>
>>>> (at first I thought it was  a  video game, but was wrong);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Phillips | 2 Jan 23:45

Re: [Tux3] Tux3 report: A Golden Copy

On Friday 02 January 2009 12:17, Martin Steigerwald wrote:
> Am Mittwoch 31 Dezember 2008 schrieb Justin P. Mattock:
> > I guess this is what is confusing to me:
> > atomic commit, btree-based versioning.
> 
> Ah, the buzz words. ;)
> 
> The tux3 mailing list contains quite some design notes about these 
> concepts. I think others can give better answers about these concepts - I 
> think I understood what it is for, not the implementation details. But 
> basically "atomic commit" is a strategy to have the filesystem always in 
> a consistent state

Right.  Atomic commit is a term that came from the database world and
was first applied to filesystems in an LKML message from Victor
Yodaiken back in 1998 as I dimly recall, and I adopted it to describe
the tree ased atomic update strategy I was developing for Tux2 at the
time.  Tux3 uses a new logging variant that is supposed to avoid the
write-twice behaviour of journalling and the recursive copy behavior of
WAFL, ZFS and Btrfs, so should be pretty good at synchronous write
loads and generally reduce write traffic.

> and btree-based versioning allows to keep different  
> versions of a file / directory around. And unlike other filesystem tux3  
> has this per inode and not for the complete filesystem. At least if I 
> understand correctly.

You do.

"Btree-based" and "versioning" are separate buzzwords.  Tux3 is a btree
(Continue reading)

Permalink | Reply | 38 comments |
headers
Justin P. Mattock | 3 Jan 00:11
Picon

Re: [Tux3] Tux3 report: A Golden Copy

Daniel Phillips wrote:
> On Friday 02 January 2009 12:17, Martin Steigerwald wrote:
>   
>> Am Mittwoch 31 Dezember 2008 schrieb Justin P. Mattock:
>>     
>>> I guess this is what is confusing to me:
>>> atomic commit, btree-based versioning.
>>>       
>> Ah, the buzz words. ;)
>>
>> The tux3 mailing list contains quite some design notes about these 
>> concepts. I think others can give better answers about these concepts - I 
>> think I understood what it is for, not the implementation details. But 
>> basically "atomic commit" is a strategy to have the filesystem always in 
>> a consistent state
>>     
>
> Right.  Atomic commit is a term that came from the database world and
> was first applied to filesystems in an LKML message from Victor
> Yodaiken back in 1998 as I dimly recall, and I adopted it to describe
> the tree ased atomic update strategy I was developing for Tux2 at the
> time.  Tux3 uses a new logging variant that is supposed to avoid the
> write-twice behaviour of journalling and the recursive copy behavior of
> WAFL, ZFS and Btrfs, so should be pretty good at synchronous write
> loads and generally reduce write traffic.
>
>   
>> and btree-based versioning allows to keep different  
>> versions of a file / directory around. And unlike other filesystem tux3  
>> has this per inode and not for the complete filesystem. At least if I
(Continue reading)

Permalink | Reply | 35 comments |
headers
Daniel Phillips | 3 Jan 02:19

Re: Tux3 report: A Golden Copy

On Friday 02 January 2009 15:11, Justin P. Mattock wrote:
> The game that came to mind when I first
> heard of tux3(I had to google a bit to find the name)
> was tux racer.  :^)
> quick question:
> what is the state for security file labeling for
> SELinux on this filesystem?

There is a lot of interest in security labels.  You are not the first
to ask.

Tux3 variable inode attributes are ideal for implementing security 
labels efficiently, way more lightweight than extended attributes.  
Otherwise, we would like to know exactly what people want.

Regards,

Daniel
Permalink | Reply | 32 comments |

Gmane