Blogs

GSoC 2009 Project: CIFS Client Implementation

Blog post by Obaro Ogbo on Wed, 2009-04-22 17:20

Greetings one and all!
I am Obaro Ogbo, one of the students selected for GSoC 2009. I also use the name nastee on irc and on Haiku Bug Tracker. I am a 3rd year student of Computer Science and Technology at Bells University of Technology Ota, Nigeria, and it appears I'm the first ever Nigerian GSoC student :-).

I began programming with Java, then learnt C before studying C++. I've done little PHP and Perl coding, however I'm learning Lisp presently. I participated in the Nigerian ACM/ICPC in 2007 and 2008 where my team came 3rd and 2nd respectively.

My primary OS has been linux (Debian/Ubuntu) since 2006. In my attempt to understand Operating Systems, I've tried lots of different OSes including OpenSolaris, GNU/Hurd and FreeBSD. I *discovered* Haiku in December 2008 but didn't run it till early 2009 and its quick boot time, responsiveness and general clean light feel got me hooked. It also seemed tailor made for me(an OS well developed, but very far from finished, so I can follow and participate in its development). I'm interested in low-level programming, but I've never really done any. I hope to get into kernel level development, understand compilers intimately and networking technologies.

Following is my project proposal as submitted.

Project Details

* Project title - Implement a CIFS client

* List of project goals

1. Implement haiku native filesystem interface
2. Copy data structure and header files that handle protocol definitions
3. Implement Protocol Negotiation, User Authentication and other session requests
4. Implement Directory requests
5. Implement file requests
6. Include encryption routines
7. Write a GUI frontend to mount cifs volumes
8. Implement Unix Extensions.
9. Optimize and test

* Description of project goals

1. fs_interface.dox and fs_modules.dox describe how to do this.
2. Linux's cifs implementation contains definitions for CIFS/SMB data structures which I'll largely use as is.
3. Implement LANMAN2.1 and NTLM 0.12 dialect negotiation, SESSION_SETUP, LOGOFF, TREE_CONNECT, TREE_DISCONNECT and File System Information queries.
4. Directory Requests are well documented in the SNIA/CIFS Technical Reference, I'll implement requests and actions for responses.
5. There are a large number of file commands, and I expect to spend the most time in this step due to that. Similar to Goal 4.
6. Implement NT and LM authentication modes and make default
7. Graphical frontend to mount a share with user providing servername, sharename, username and password.
8. These are small enhancements to enable Unix/Unix-like clients and servers exchange information used by both e.g symbolic links.
9. Mainly try to optimize features like read-ahead and write-behind, and test extensively

* Why I want to work on this project

- I hope to understand an Operating System in its entirety, preferrably one not fully developed, so I can follow design decisions and help code someday. Haiku provides this opportunity, and implementing this project will serve as an entry point. I enjoy learning new things, and I've already learnt so much from researching this project I can hardly wait to start.

Update DriveSetup/Disk_Device

Blog post by bebop on Wed, 2009-04-22 04:21

I live in Honolulu Hawaii, I enjoy Surfing, Swimming, Sun and Code. I am working on my BS in Computer Science at the University of Hawaii at Manoa and minoring in Geography. Next year will be my senior year. I have taken courses in concurrent programming as well as networking. Next year I will be taking an operating systems course. I also have some experience in machine architecture and optimization. My current side project is writing an application for the Geography Department, that is a complete suite of tools for stereogrammetry. My professional work has been work on an electronic medical health records system based on the United States Veterans Affairs VistA system. I have more recently worked for Nanopoint Imaging Inc. working on live cell imaging and microfluidics software.

Project: Finalize Design and Implementation of the Disk Device Framework and DriveSetup Application.
I would like to complete the implementation of the DriveSetup application for Haiku. The application is a key feature of Haiku and is currently in the Haiku bug tracker as an Alpha milestone.

To Complete this task will require:

Disk Device Framework:

  • Collaborate with mentors to finish work on the Disk Device Frame work.
    • Add partition/partition map creation to the Disk_Device API
    • Add partition/partition map deletion to the Disk_Device API
    • Finish Intel Partition Add on, in particular finish Extended Partition support.
  • Design and implement modules that the team deems necessary to complete the Disk Device framework.

    DriveSetup:

  • Update the DriveSetup UI to reflect the changes in the API
    • Add creation of Intel style partition maps.
    • Add creation of partitions of popular file system types.
    • Add deletion of partition maps and partitions.
  • Adapt DriveSetup to Haiku's layout system.
  • Apply MVP design pattern to all newly created code.

    Implementing the Intel style partition map (MBR) and extended partitions (EBR) can be done by following the data structures that have been well documented. The source code from Linux, and the BSD's as well as the various partition tools could be used as a starting point for integration into the operating system. The creation and deletion of these structures on disk will then be dependent on how well the implementation follows the data structures. Writing the DriveSetup application should then be a matter of creating a mock up then designing the correct views from the BeAPI.

    BeOS sparked my interesting in alternative operating systems way back in 8th grade. Since then I have watched Haiku/OpenBeOS and have always wanted to help but was unable to write code. Now that I have some experience as a paid programmer I feel that I can finally make a commitment to complete a project I set out to accomplish. I feel that I would be a good candidate for the project because I have experience in breaking a project into small tasks that can be completed by a fixed deadline. I have also become good at making time estimates on how long a particular task should take to be completed. I also believe that I have the technical skills to finish the project that I have outlined above, and would be excited to be given the chance to do so.

  • Implementing ZeroConf support for Haiku with mDNSResponder

    Blog post by majie on Wed, 2009-04-22 03:43

    Personal Profile

    • Ma Jie
    • Brief bio
    • My name is Ma Jie, And Jie is my given name. I'm a senior college student from China. Although not majored in Computer Science, I still love to do computer programming in my spare time. I have a National Computer Rank Examination certificate on computer network technology and got third prize of a national Java programming competition. The PoorMan server of Haiku is my first contribution to the open source world. I learned a lot from it, and I think it's time to contribute my knowledge back.

    Project idea information

    • Project title
    • Implementing ZeroConf support for Haiku with mDNSResponder

    • List of project goals
      1. porting mDNSResponder to Haiku
      2. a mDNSResponder configuration preflet, which can be integrated into the network preflet in the future
      3. a services browser and notifier, which may be integrated into the Deskbar
      4. making PoorMan server utilize the ZeroConf network
      5. writing test cases and running the tests
    • Project description
    • There are two major implementations of zero configuration networking, Avahi and Apple's Bonjour. mDNSResponder is the underlying component of Bonjour. There are several reasons for me to choose mDNSResponder as the Haiku's ZeroConf engine. First, as Avahi is mainly designed for linux and BSDs, it uses GNU Autotools, while mDNSResponder uses handmade makefiles. Since Haiku's build system consists of a lot of Jamfiles, mDNSResponder will be easier to integrate into the source tree. Second, Avahi lacks porting directions. Finally, Haiku prefers Apache license that is more compatible with Haiku's MIT license to LGPL.

      There may be some difficulties when porting mDNSResponder to Haiku, because the cross platform support is abandoned and some gcc incompatible codes was added to the sources. I need to fix the broken codes during the porting procedure. mDNSResponder will run like other Haiku components. A server runs in the background and clients that want to use the ZeroConf services can communicate with the server by a library.

      Goal 4 not only lets the PoorMan server broadcast its service to a local network, but it can be a demonstration to other Haiku services on how to use the ZeroConf network.

    • Why do you want to work on this project?
    • I think I can work on this project, because I ported thttpd as the backend of PoorMan server to Haiku and I learned some useful skills on porting codes to Haiku. If I can work on this project, with these experiences I can do better in my future contribution to the Haiku project.

    Porting Haiku to ARM architecture

    Blog post by pfoetchen on Tue, 2009-04-21 23:35

    Personal Profile

    • Johannes Wischert
    • Brief bio - I'm a computer science student living in Germany. I'm 25 years old now. I wrote my first program with 8 or 9 years or so and never stopped since then... After my studies I want to work somewhere in the embedded systems development but by now I enjoy my studies and take my time to finish.

    Project idea information

    • Project title - Port the Haiku Kernel to ARM-Architecture
    • List of project goals -
      • generic u-boot Bootloader using the u-boot apis as far as possible to ease porting to other platforms that use u-boot
      • Kernel that runs on the arm-processor and supports all applicable features that the x86 kernel has
      • Device driver for at least the SD-card and the Serial-Port
      • Working system running on a Beagleboard or similar device
    • Project description -
      • To get the system running on an ARM-CPU we first need a working Haiku ARM toolchain to compile the code I already got the toolchain to run and produce working binaries (tested under qemu) so this part of the system already works more or less. see: http://dev.haiku-os.org/ticket/3633
      • After that done the next step is the boot loader. Since the beagleboard I want to target already has "Das U-boot" bootloader installed I decided to use it to get the kernel loaded. Using the u-boot loader has some advantages since it already provides all the important data and functions for loading the kernel like builtin serial drivers and drivers for all kind of memory to boot from (including a TFTP client) these functions are exposed by a simple platform independent API. By using this API an architecture independent kernel loader could be build, so that porting to other architectures that use u-boot would be much easier.
      • The loader would run as a standalone application on top of u-boot to use it's features and then switch to direct access to the hardware to run the kernel.
      • To allow u-boot to boot the kernel I could either include bfs in u-boot or implement the bfs in the loader programm. If the bfs code is in the loader no change to u-boot is needed so I will probably take this way since changing the u-boot always has the risk to brick a device.
      • I know that this is not everything and I will probably have to ask a lot of questions to get everything right ;)
      • I must admit that I don't know to much about the ARM internals, yet so I can't give much details about how I will port the MMU dependent stuff etc.
      • The device drivers for the serial-port and the sd-card are quite straight forward to implement, since they are interfaced directly by the processor (at least on the beagleboard) and there are a lot of existing open source drivers (of course we would have to pay close attention to the licenses etc...)
      • Since the beagleboard does not have an isa or pci bus it could use code similar to the m68k port to put the onboard devices in the pci bus. Even better would be to write a sort of bus system for the onchip devices this would also help to port to other devices that do not realy have a bus system like many other embedded devices.
      • The next steps would be to write a driver for the onchip usb-controler and a Framebuffer driver if the porting goes much faster than I think ;)
    • Why do you want to work on this project?
      • I love the whole concept of Haiku and would love to see it run on embedded hardware like all these planned linux+arm netbooks. Since ARM-CPUs are used in so many different devices and most of these devices are multimedia devices like netbooks/mediaplayers/smartphones it would make sense to port Haik as an multimedia OS to these devices.
      • I already have experience in embedded programing for example I ported an OS from the MSP430 to the SuperH Architecture for university (it was a nano kernel OS called SmartOS there is a wiki about this project but for whatever reason they have the interesting parts hidden http://www5.informatik.uni-wuerzburg.de/snow5xoops/modules/dokuwiki/doku...? ) so I know a bit about all the problems that could arise.
      • I know porting such a complex project is quite difficult but I have the time to concentrate on this project and it's not the first embedded project I work on (but probably the biggest ).
      • Other projects I worked on were a device driver for the r4ds flash card to use it under DSLinux on the Nintendo DS and some other smaller stuff like a stepper motor controler board that was controlled by an MSP430.
      • I know that this project is not really helpful to get closer to the first alpha release of haiku but I think an ARM port would be a interresting addition to the Haiku project and perhapse attract some more developpers.

    Integrate WebKit in Haiku native browser, My GSoC proposal.

    Blog post by maxime.simon on Tue, 2009-04-21 14:13

    Personal Profile

    • Maxime Simon

    • Brief biography:

      I am currently in my third year studying Computer Science at Rennes 1 University in France.

      I have some experience with development thanks to several academic projects, chiefly written using the Java and C languages.

      Our first big project used an obscure language called "oRis", an object and agent-oriented language developed as part of the doctoral thesis of Fabrice Harrouet. The project's objective was to design a simulation of pathfinding robots, with basic behaviour and capable of cooperating to achieve goals in a virtual maze. This project enabled us to learn how to manage a project using Subversion, and how to organise its development.
      The project was managed at this page:
      http://code.google.com/p/csr/

    GSoC project : Internationalization for Haiku

    Blog post by PulkoMandy on Tue, 2009-04-21 08:02

    Hello world !
    As you know, I am one of the selected students for this year summer of code. In this post I will introduce myself and give some details about my project.

    My name is Adrien Destugues, some of you may know me as PulkoMandy as i've been lurking on the irc channel and mailing lists for some time. I already applied for the Summer of Code and Haiku Code Drive last year but unfortunately I was not selected. This year it went better :)
    I'm studying electronics and computer science at the ENSSAT (École Nationale Supérieure de Sciences Appliquées et de Technologie), in Lannion, France. I used to run BeOS as my main operating system for some time, but I now switched to Linux. I have a running Haiku install on my hard disk, but as my network card is not supported, I don't use it much for everyday work. I hope this will change soon.

    Now, some information on my project: the idea was born because we were talking about "which os is better" on the ENSSAT mailing list, between linux, mac os X and windows (the kind of endless discussion student have all the day long ;)). I sent a link to Haiku homepage to point the fact that there was other alternatives, and someone replied "hey, it doesn't even speaks french!". This fact is quite annoying for an operating system targeted to regular users, and not powerful computer geeks. Not everyone speaks english, and this is what an user will see first when running Haiku for the first time. So I decided to improve that and get Haiku internationalized. I did some research on the web and found informations about localization under BeOS. There was a locale kit in zeta, but the Haiku team had already started another project as part of Open Tracker. It was not integrated into Haiku because of some problems, the main one being the way the Be API is used to create windows. As the translated texts have a different length than the original ones, the window may look bad with overlapping texts and other problems similar to font sensivity.
    The Layout system can now solve that, so it's about time to get the Locale Kit back to work.

    The locale kit must do various things. It provides a way to translate strings, of course, but also offers services for formatting date, time, numbers and currencies. Each country have different rules for that, and any program can ask the locale kit to do the formatting properly. Another service is a natural order sorter, which sort a set of strings alphabetically but with special rules for accents, diacritics, and so on. Of course, all of this has to be done at runtime. This way the language is selected and configured with a simple preflet and all opened applications are instantly translated.
    Some kind of compatibility with zeta locale kit and gnu gettext would be nice, it would allow to use translations from other systems, either directly or by using a conversion tool.

    The basic layout for all that is already in place in OpenTracker's Locale Kit. However, most of the code is not written, for example there is no code for date formatting, for loading Zeta's catalog files. The API is well designed, so I will keep most of it, and fill in the missing functions. The ICU library will be used as a backend for everything except the translation. It provides all the needed data for doing all the formatting work properly.

    The translation can be done with string-based or key-based lookup. The Locale Kit handles a list of catalogs, some of them are specific to an application and some are system- or user-wide. Catalogs can be stored on hard disk as plain files, resources in an application executable or bfs attributes. Catalog format can be added in the form of add-ons.

    List of project goals
    1) Integrate OpenTracker's Locale Kit to the Haiku build system. I've already got it building as part of the 3rdparty/ folder, and got the basic tests working. However a proper integration will need to get out of 3rdparty and fully integrated to the build system.
    2) Create an example localizable "Hello World" application and test it. It will allow two things: testing of the kit and showing to programmers the way to use this kit properly.
    3) Integrate the ICU library to do the collation (alphabetical sorting) and date/time/number/currency formatting. Don't try to reproduce their huge work in getting a database for all the countries. Modify their code so it compile cleanly under gcc2 (if needed) and integrates cleanly in the Be API.
    4) Design and create a preflet for easily changing the language while running Haiku. It will have the following features :
    * edit the settings for date, numbers and currencies and save them as user defined settings,
    * allow to change the default settings for a country for all these settings,
    * allow the user to select his preferred languages in a sorted list.
    5) Create tools for translating an application. We need to extract translatable strings from a .cpp source file, and to save a compiled catalog for use at runtime. The current tools are working only under Haiku, and we need them under linux as part of Haiku's build process. If needed, change the catalog format to make it easy to work with, or add an importer add-on to read and write text files.
    6) Write an importer (catalog add-on) for Zeta's catalogs and test it with some applications providing a Zeta catalog.
    7) Write an importer for GNU gettext format.
    8) Modify the code of all the preflets and applications in haiku so they use the localization system (if there is some time left at the end of summer ;))

    R1/Alpha : Welcoming the Newcomers

    Blog post by stpere on Tue, 2009-04-07 16:00

    Context

    Imagine the release just got out the door; what needs to be ready at this point to get everything running smoothly ?...

    Newcomers

    We need some structure to welcome newcomers (developers and others) effectively. I think many -- everything is relative -- people with various skills will come and may ask things like :

    1. Where can I help ?
    2. I want to port [insert favorite software from linux] !!!!
    3. Many others...

    We should make sure that we can "steer" them to the correct teams (according to their tastes).

    My understanding is that the team concept is quite loose at the moment. It fits well with a relatively small core of developers, since it doesn't add unnecessary "ceremony". But I think as the community will grow, it might be useful to have some light structure. There would be no bosses for say, but welcomers, mentors. They would be a small set of people that knows the inners of the topics relative to the team tasks and can help the beginners to get started, invite them to suscribe to the MLs, etc..

    We should stress out the fact that at that point, we need more than coders.. We will need people in those teams too :

    1. User guides, documentation,...
    2. Artwork
    3. Quality Assurance
    4. Public Relations
    5. ...

    Some other peoples will without any doubts try Haiku out of curiosity, and know almost nothing from it before hand, and we might need to be able to answer their questions. A good first approach possibly means that they will share their experience with friends, and you see the cascade coming right? Depending the volume of those requests, it can be quite time consuming to answer verbosely to everyone.. So we should make sure the user guide is so good that we will gladly point them to it! :) But it might be nice to have some PR representants to help answer the questions.. ;-)

    Again, comments welcome, it's definitely not complete nor definitive.. Just some food for thoughts :)

    Syndicate content