On Fri, 24 Oct 2014 14:53:06 +0200
Arvin Schnell <[email protected]> wrote:

> 
> Hi,
> 

Hi Arvin,
thanks for sharing, I post below some comments.

> my hackweek project was to evaluate using the boost graph library
> (BGL) in libstorage. For me the project was interesting and
> successful. I have documented it at
> https://github.com/aschnell/libstorage-bgl-eval/wiki. The code is
> also available there.
> 
> So now I would like to redesign the storage part of YaST. Here
> are the main steps required:
> 
> - Extend libstorage-bgl-eval to fully support disks, partitions
>   and simply filesystems (probing, committing, testmodes,
>   testsuite).
> 
> - Try to make a compatibility layer.

yes, compatibility layer is needed to smooth migration.

> 
> - Make the new API robust against API and ABI changes.

Sounds good, question is how?

> 
> - Export new API to Ruby (help would be good) for use by all YaST
>   modules.

I think it would be very cool if we have in ruby nice object oriented
API. I can help you with ruby bindings. I think it is usually better to
have combination of C bindings and ruby code that make usage in ruby
smoother.

> 
> - Get a simply installation working (two partitions, ext4 and
>   swap).
> 
> - Extend libstorage-bgl-eval to current libstorage
>   functionality. Maybe drop a few features, e.g. loop-back
>   devices (once used for encryption).
> 
> - Make the new API suit the needs of all YaST modules (input from
>   other developers required). If required add utility functions.

I think that if only one module need specific functionality, then it
should do it itself. ( like bootloader do setting pmbr flag for disks ).
If more modules need it, then it make sense to have it in libstorage.

> 
> - Make all code in YaST use new API (task for several
>   developers).

For this step we really need some storage setup factory, so e.g. in
bootloader I can replace old mocks of target maps with new stuff and
change code.

> 
> - Make expert partitioner use new features, e.g. use disks
>   without partition table for filesystems.
> 
> - Rewrite storage proposal (specification required!).
> 
> - Finally drop target-map (as decided during workshop).

That will be great step especially together with object oriented API.
Then we can have something like Disk.find( bios_id:
"0x80").find_partition(mount_to: "/boot").sw_raid? in bootloader.

> 
> - Drop compatibility layer.
> 
> In the end yast2-storage would ideally only contain dialogs and
> no logic for other YaST modules (since all of that moved to
> libstorage). But if some utility functions are easier to
> implement in Ruby they can stay there.

I think utility can be in ruby bindings of libstorage if it is easier
to do it there.

> 
> I assume that altogether the redesigning will take more than half
> a year. Anyway I think it is required to keep the code
> maintainable and be prepared for new feature requests. Some
> existing features request might already be implemented along the
> way (e.g. https://fate.suse.com/316251).
> 
> ciao
>   Arvin
> 

Josef
-- 
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]

Reply via email to