Re: [Xen-devel] [RFC PATCH 00/11] tmem: some basic cleanup

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Tue, Nov 05, 2013 at 09:03:47AM +0000, Jan Beulich wrote:
> >>> On 05.11.13 at 03:04, Bob Liu <bob.liu@xxxxxxxxxx> wrote:
> > On 11/04/2013 11:56 PM, Jan Beulich wrote:
> >>>>> On 04.11.13 at 13:40, Bob Liu <lliubbo@xxxxxxxxx> wrote:
> >>> There are too many typedefs and referenced once functions in tmem, 
> >>> perhaps 
> > the
> >>> reason was tmem was designed can be ported to other hypersivor easily.
> >>> But when I try to read tmem source code, some of them are not very
> >>> straightforward. This patchset try to clean up them. It's only my 
> >>> thoughts 
> > so I
> >>> tag this patchset with RFC.
> >> 
> >> If I was the maintainer, or as to make a recommendation, I wouldn't
> >> accept these changes - they were done for a purpose after all. If
> >> anything a re-work from grounds up would seem the only reasonable
> >> option.
> >> 
> > 
> > Well, I'd like re-work tmem from ground also.
> > But currently it's too difficult for me to re-work it since I don't have
> > enough knowledge. It's hard for me to understand tmem quickly because of
> > its order of complexity and I'm not fit to its coding style.

The coding style is a Xen style - it takes a bit of use to it as
it is different from the Linux one. (I am still struggling with it).

> > 
> > Clean up patches will also be the first step even reworking it from
> > grounds unless we can start with a new better/simpler tmem.c
> > implementation and replace current one directly.
> 
> That's actually what I meant with "from grounds up" - just start
> over (mostly) from scratch.

I am not sure why that is advocated.

I really prefer that the existing code be fixed up/altered/changed/made
more readable/fixed. When that has been completed and if the design is
bad - then perhaps reworking team from ground up could be considered.

But that can be done alongside - similar to how event channel mechanism
has now two implementations.

Now long-term ahead - some of the esoteric features - like de-duplication,
compression, etc. Those can be moved to different parts of the code as they
are more complex (And make the structures harder to understand). Perhaps
to a different file. Thought all of them are pretty awesome features.

There are also two locking mechanism. The 'big lock' (not in usage, but
could be in use for debugging) and the normal lock. The 'big lock' could go
away. If there is contention the locking can be reworked to be more optimal.

> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel