Re: Getting Started

Re: Getting Started

[Steve Burtchin]

[-- Attachment #1.1: Type: text/plain, Size: 9272 bytes --]

On Tue, 10 Apr 2012 14:26:54 +0200 Vladimir '?-coder/phcoder' Serbinenko wrote:
>On 10.04.2012 12:56, Steve Burtchin wrote:
>> I found the URL to the bug report.  It is
>> http://savannah.gnu.org/bugs/?19410.  In summary (and more
>> specifically), I wish to add the following features to the GRUB2
>> 'parttool' command:
>>  
>> 1) Create or delete a primary partition.  This functionality was
>> provided by the 'partnew' command in GRUB Legacy.  See also
>> http://savannah.gnu.org/bugs/?19389.
> As I've explained in a parallel thread (the one concerning SoC), any
> writing to disk is potentially dangerous and so we need a good reason to
> do it. Why would you want to regularly create and destroy partitions in
> GRUB?

Firstly, I do not wish ever to create or destroy any partition using GRUB.  I was using the terminology from the GRUB legacy manual: "partnew . . . Create a new primary partition."  IMHO this would be more appropriately described as "Edit a slot in the MPT (to define an alternate primary partition)."  The corresponding terminology ("delete") would IMHO be more appropriately described as "Zero a slot in the MPT (to thoroughly hide a primary partition from aggressive installers)."  For example, suppose I want to install WindowsXP to hda3.  The safest approach would be to create a menuitem in grub.cfg to zero out slots 1, 2 & 4 of the MPT, and then boot the CD.  The installer then only sees one partition with the rest being free space, for which it will ask you before overwriting it.

Secondly, in regards to the 'SoC' thread, any changes to the partitioning layout would obviously make the current 'menu.cfg' file obsolete, and therefore, any practical integration of parted with GRUB would necessarily require that 'menu.cfg' be updated in lockstep.  With the exception of small adjustments, I would agree that in almost all cases (all) the partitioning work should be done prior to installing any bootloader.  In this respect, the intended use of my proposed new functionality (wrt. item 1) would be esentially identical to that of the 'gptsync' command, the only difference being that the source of the MPT data would reside in 'menu.cfg' rather than in the GPT partition entries.

>>  
>> 2) Edit extended partition tables (EPBRs).  This functionality was
>> added to GRUB Legacy with the 'eptedit' command as described in bug
>> report #19410.
>>  
> I feel like improvements into our gptsync (i.a. support for creating
> secondary partitions when possible) solves the same problems (having
> more than 4 OS requiring primary partitions) but in a more standartised
> way and with a benefit of that GPT-aware tools will handle the whole
> thing correctly.

It is entirely true that with a GPT partitioned disk and 'gptsync' one could setup GRUB2 to boot more than 100 GPT-unaware operating systems each requiring its own primary partition to boot.  However, in practice this is severly restrictive in the great majority of computers sold for home use (and business workstation computers) which have only one HDD.  With only one HDD, this leaves only two other partitions for sharing and storing data for GPT-unaware OSs.  Each older OS has its own caveats as to which filesystem types it can use.  Having a universal data-share partition in FAT16 (or FAT12) would not be practical in many situations involving modern OSs, so at least two data sharing partitions are usually needed for practical reasons in a mix with old an new OSs.  There are also good reasons for wanting more than one partition for data storage.  These too must be compatable with the caveats of the OSs wanting to use them.  Further if a second disk is added it will likely be greater than 2TB in the near future, necessitating that it too will be GPT partitioned, resulting in a net gain of only 3 more available partitions for any GPT-unaware OS.  So for the greater majority of current PCs, and especially those purchased before 2012, the only flexible solution for those who want to include GPT-unaware OSs is that at least one HDD be MBR partitioned -- that being the first HDD.  There is also the issue that with a GPT partitioned disk, all such GPT-unaware imaging tools one might have (and like using, eg. Ghost) and other utilities (eg. PTEDIT) would become unusable.

If a user has only GPT-unaware OSs, the only benefit to be gained with a GPT partitioned disk is that setup of a multiboot system may in some cases be easier, but with the severe tradeoffs in flexibility already mentioned.  One could, in theory, dedicate one GPT partition in the hybrid MBR as a logical partition, but this partition would have to be hidden from all GPT-aware OSs, and such a partitioning layout would not be directly supported by any one partitioning utility.  There are also known (and potentially unknown) problems when using hybrid MBRs (see http://www.rodsbooks.com/gdisk/hybrid.html).  I would speculate that 'gptsync' could be used to zero out slots 2, 3 & 4 of the MPT before booting any problem OS, and before using any utility not known to be safe with hybrid MBRs, but these issues are usually not known until it is too late (and wrt. using utilities, it is easy to forget to do so).

The typical usage for my 'eptedit' command was to zero out the second slot of an EPBR (combined with redefining the size of the extended partition with 'partnew') such that a much shorter extended partition could be presented to OSs not capable of accessing more than 1024 cylinders.  For LBA-aware OSs 'eptedit' was used to repopulate the second slot of this EPBR.  The same technique might also be used on large disks for OSs subject to the 128GiB barrier.  I also used 'eptedit' in this way to hide non-FAT partitions at the end of an extended partition from Win9x OSs to avoid the 'Last Logical Partition Bug'.

Here is an example (see attached file "file #12285 SecMastr.png"):
Note that there are two alternate definitions for the extended partition hdb2.  The shorter extended partition definition is used for booting all OSs that use CHS addressing.  The longer extended partition definition is used for booting all OSs that use LBA addressing.  When using the shorter extended partition definition, the EPBR at hdb15 should have all zeroes in the second slot of its partition table (see attachment "file #12289  b15_old.png").  When using the longer extended partition definition, the EPBR at hdb15 should have the second slot of its partition table populated with the information for the next logical partition (see attachment "file #12286 b15_std.png").

>> NOTE: Not mentioned in the original bug report: with the ability to
>> edit EPBRs, the potential number of logical partitions is limited only
>> by the disk geometry for any SATA, PATA or SCSI disk.

In one of my multiboot PC's with a single HDD I had 35 logical partitions.  Most held OSs.  Some were small unused placeholders used to occupy a drive letter such that all MicroSoft OSs would recognize all partitions (that each could see) by the same drive letters.  MicroSoft OSs at least thru WindowsXP and many utilities cannot function predictably with this many logical partitions.  To work around these issues, I used my 'eptedit' command (ref: http://savannah.gnu.org/bugs/?19410) in GRUB Legacy to rewrite one or more EPBRs to skip over some logical partitions, or to present a truncated extended partition to the OS.  Potentially the same technique could be used (with much flexibility wrt. data and sharing partitions) to boot hundreds of OSs.  For OSs requiring their own primary partition to boot, I used 'partnew' to (duplicate) define a logical partition as a primary partition (eg. I used this technique to boot DOS v5.0 residing on a logical partition).  This is essentially identical to what you are doing with 'gptsync', but with the flexibility that you would still have potentially 20+ partitions available to the GPT-unaware OS.  These same 20+ partitions would also be available to any GPT-aware OS.

I would agree that with a mix of only GPT-aware OSs, and in some (rare IMHO) situations in a 2+ HDD system with a mix of GPT-unaware and GPT-aware OSs (assuming at least one HDD is MBR partitioned), it would be superior to have the first HDD GPT partitioned.  However, in a single disk system, and in systems where the second HDD is > 2TB, it is MHO that the superior arrangement would be to have the first HDD MBR partitioned.  In these systems (the greater majority in existence today) this provides the greatest amount of flexibility in terms of the quantity of common partitions available to all GPT-unaware and GPT-aware OSs (and GPT-unaware imaging tools).

As you said, writing to disk always carries some risk, however, it is JMHO that it is far safer writing to the partition tables in a controlled way using GRUB than to create a hybrid configuration when it is not an essential requirement for booting.  With the proposed new features, the most common problem that might occur would be some mucked-up partition tables that would be easy to recognize and fix.  I believe it to be a much greater risk to introduce a hybrid state where an unsuspecting user might try to use a GPT-unaware partitioning or data recovery tool.

[-- Attachment #1.2: Type: text/html, Size: 10962 bytes --]

[-- Attachment #2: file #12285 SecMastr.png --]
[-- Type: image/png, Size: 25657 bytes --]

[-- Attachment #3: file #12289  b15_old.png --]
[-- Type: image/png, Size: 3112 bytes --]

[-- Attachment #4: file #12286 b15_std.png --]
[-- Type: image/png, Size: 3401 bytes --]

Re: Getting Started

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 4561 bytes --]

On 13.04.2012 11:39, Steve Burtchin wrote:
> On Tue, 10 Apr 2012 14:26:54 +0200 Vladimir '?-coder/phcoder'
> Serbinenko wrote:
> >On 10.04.2012 12:56, Steve Burtchin wrote:
> >> I found the URL to the bug report.  It is
> >> http://savannah.gnu.org/bugs/?19410.  In summary (and more
> >> specifically), I wish to add the following features to the GRUB2
> >> 'parttool' command:
> >> 
> >> 1) Create or delete a primary partition.  This functionality was
> >> provided by the 'partnew' command in GRUB Legacy.  See also
> >> http://savannah.gnu.org/bugs/?19389.
> > As I've explained in a parallel thread (the one concerning SoC), any
> > writing to disk is potentially dangerous and so we need a good reason to
> > do it. Why would you want to regularly create and destroy partitions in
> > GRUB?
>  
> Firstly, I do not wish ever to create or destroy any partition using
> GRUB.  I was using the terminology from the GRUB legacy manual:
> "partnew . . . Create a new primary partition."  IMHO this would be
> more appropriately described as "Edit a slot in the MPT
Please stop inventing your own shortcuts, it makes it difficult to read
and understand you.
> (to define an alternate primary partition)."  The corresponding
> terminology ("delete") would IMHO be more appropriately described as
> "Zero a slot in the MPT (to thoroughly hide a primary partition from
> aggressive installers)."  For example, suppose I want to install
> WindowsXP to hda3.  The safest approach would be to create a menuitem
> in grub.cfg to zero out slots 1, 2 & 4 of the MPT, and then boot the
> CD.  The installer then only sees one partition with the rest being
> free space, for which it will ask you before overwriting it.
Not true. Some installers take free space to silently create some
partitions it believes should be "always present". Moreover most of
concerned OS ignore partitions with unknown type so just setting hidden
flag is enough.
>  
> Secondly, in regards to the 'SoC' thread, any changes to the
> partitioning layout would obviously make the current 'menu.cfg' file
> obsolete, and therefore, any practical integration of parted with GRUB
> would necessarily require that 'menu.cfg' be updated in lockstep. 
> With the exception of small adjustments, I would agree that in almost
> all cases (all) the partitioning work should be done prior to
> installing any bootloader.  In this respect, the intended use of my
> proposed new functionality (wrt. item 1) would be esentially identical
> to that of the 'gptsync' command, the only difference being that the
> source of the MPT data would reside in 'menu.cfg' rather than in the
> GPT partition entries.
You need partition table in the first place in order to access grub.cfg
(and it's not menu.cfg).
> >> 
> >> 2) Edit extended partition tables (EPBRs).  This functionality was
> >> added to GRUB Legacy with the 'eptedit' command as described in bug
> >> report #19410.
> >> 
> > I feel like improvements into our gptsync (i.a. support for creating
> > secondary partitions when possible) solves the same problems (having
> > more than 4 OS requiring primary partitions) but in a more standartised
> > way and with a benefit of that GPT-aware tools will handle the whole
> > thing correctly.
>  
> It is entirely true that with a GPT partitioned disk and 'gptsync' one
> could setup GRUB2 to boot more than 100 GPT-unaware operating systems
> each requiring its own primary partition to boot.  However, in
> practice this is severly restrictive in the great majority of
> computers sold for home use (and business workstation computers) which
> have only one HDD.  With only one HDD, this leaves only two other
> partitions for sharing and storing data for GPT-unaware OSs.
As I said: I'd rather add a support for creating extended partitions in
protective MBR.
>  
> If a user has only GPT-unaware OSs, the only benefit to be gained with
> a GPT partitioned disk is that setup of a multiboot system may in some
> cases be easier, but with the severe tradeoffs in flexibility already
> mentioned.  One could, in theory, dedicate one GPT partition in the
> hybrid MBR as a logical partition, but this partition would have to be
> hidden from all GPT-aware OSs, and such a partitioning layout would
> not be directly supported by any one partitioning utility.
One would have regular GPT partitions with few gaps, or special type
partitions left for putting EBR there.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

getting started...

[Ed Sutter]

Hi,
I'm new to Yocto.  I've used it to build/install linux on the Wandboard, 
and I've installed
host-based cross devlopement environment (bitbake -c populate_sdk ).  
Everything worked, but
basically I just followed some "getting started" steps so, I still don't 
really have a clue...

Last year I finished up a custom iMX6-based project using buildroot for 
rootfs, ftp.denx.de
for uboot and freescale git for the kernel.

These two projects are totally isolated; yet I'm sure >85% of the code 
base is identical.

This year I have two ongoing iMX6 based linux projects, and may need to 
use a beaglebone
or RPi for some other small project.

The point of the above detail is that I'd like to backup a bit and 
attempt to use Yocto to
organize all four of these with one instance of Yocto/Poky.  Is that 
practical?  Seems
to me that is the ideal goal of Yocto, but I don't see many BSPs listed 
under the project
downloads page.  On the other hand, I know wandboard and sabresd and 
many others do have
yocto build environments.

What's the scoop on that?

I'd really like to manage all of these projects under one umbrella if 
possible; but what
if different projects use different versions of poky (for example)?

Thanks in advance for any info...
Ed

Re: getting started...

[Trevor Woerner]

Hi Ed,

On 05/27/15 16:32, Ed Sutter wrote:
> This year I have two ongoing iMX6 based linux projects, and may need
> to use a beaglebone
> or RPi for some other small project.
>
> The point of the above detail is that I'd like to backup a bit and
> attempt to use Yocto to
> organize all four of these with one instance of Yocto/Poky.  Is that
> practical?

Yes, that would be a great idea!Have a look at angstrom, for example:
http://www.angstrom-distribution.org. They build one distro for a whole
bunch of different machines. As such, they start with a whole bunch of
different layers, most of which are BSP layers, and then simply do:

$ MACHINE=<machine> bitbake <image>

e.g.

$ MACHINE=raspberrypi2 bitbake angstrom-image
$ MACHINE=beaglebone bitbake angstrom-image
...

and build the exact same image for a bunch of different boards/machines.

They've recently switched to using a repo manifest (which I think is a
great idea): https://github.com/Angstrom-distribution/angstrom-manifest

I've been playing around with doing essentially the same thing for a
"poky" distribution here (but it's still a work-in-progress and not
really ready for prime time yet): https://github.com/twoerner/layer-repos

>   Seems
> to me that is the ideal goal of Yocto, but I don't see many BSPs
> listed under the project
> downloads page.

Take a look here:
http://layers.openembedded.org/layerindex/branch/master/layers this is
the "master" list of all the "known" layers, recipes, etc. As you can
see, there are quite a few BSP layers.

Best regards,
    Trevor

Re: getting started...

[Paul Eggleton]

On Friday 29 May 2015 14:41:37 Trevor Woerner wrote:
> Hi Ed,
> 
> On 05/27/15 16:32, Ed Sutter wrote:
> > This year I have two ongoing iMX6 based linux projects, and may need
> > to use a beaglebone
> > or RPi for some other small project.
> > 
> > The point of the above detail is that I'd like to backup a bit and
> > attempt to use Yocto to
> > organize all four of these with one instance of Yocto/Poky.  Is that
> > practical?
> 
> Yes, that would be a great idea!Have a look at angstrom, for example:
> http://www.angstrom-distribution.org. They build one distro for a whole
> bunch of different machines. As such, they start with a whole bunch of
> different layers, most of which are BSP layers, and then simply do:
> 
> $ MACHINE=<machine> bitbake <image>
> 
> e.g.
> 
> $ MACHINE=raspberrypi2 bitbake angstrom-image
> $ MACHINE=beaglebone bitbake angstrom-image
> ...
> 
> and build the exact same image for a bunch of different boards/machines.
> 
> They've recently switched to using a repo manifest (which I think is a
> great idea): https://github.com/Angstrom-distribution/angstrom-manifest
> 
> I've been playing around with doing essentially the same thing for a
> "poky" distribution here (but it's still a work-in-progress and not
> really ready for prime time yet): https://github.com/twoerner/layer-repos
> 
> >   Seems
> > 
> > to me that is the ideal goal of Yocto, but I don't see many BSPs
> > listed under the project
> > downloads page.
> 
> Take a look here:
> http://layers.openembedded.org/layerindex/branch/master/layers this is
> the "master" list of all the "known" layers, recipes, etc. As you can
> see, there are quite a few BSP layers.

Furthermore, you can click on the "Machines" tab i.e.

http://layers.openembedded.org/layerindex/branch/master/machines/

Type in a keyword (or leave the box empty to see all) and hit Search, and 
you'll see a list of the matching machines provided by all the layers in the 
index.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: getting started...

[Ed Sutter]

On 5/31/2015 8:16 AM, Paul Eggleton wrote:
> On Friday 29 May 2015 14:41:37 Trevor Woerner wrote:
>> Hi Ed,
>>
>> On 05/27/15 16:32, Ed Sutter wrote:
>>> This year I have two ongoing iMX6 based linux projects, and may need
>>> to use a beaglebone
>>> or RPi for some other small project.
>>>
>>> The point of the above detail is that I'd like to backup a bit and
>>> attempt to use Yocto to
>>> organize all four of these with one instance of Yocto/Poky.  Is that
>>> practical?
>> Yes, that would be a great idea!Have a look at angstrom, for example:
>> http://www.angstrom-distribution.org. They build one distro for a whole
>> bunch of different machines. As such, they start with a whole bunch of
>> different layers, most of which are BSP layers, and then simply do:
>>
>> $ MACHINE=<machine> bitbake <image>
>>
>> e.g.
>>
>> $ MACHINE=raspberrypi2 bitbake angstrom-image
>> $ MACHINE=beaglebone bitbake angstrom-image
>> ...
>>
>> and build the exact same image for a bunch of different boards/machines.
>>
>> They've recently switched to using a repo manifest (which I think is a
>> great idea): https://github.com/Angstrom-distribution/angstrom-manifest
>>
>> I've been playing around with doing essentially the same thing for a
>> "poky" distribution here (but it's still a work-in-progress and not
>> really ready for prime time yet): https://github.com/twoerner/layer-repos
>>
>>>    Seems
>>>
>>> to me that is the ideal goal of Yocto, but I don't see many BSPs
>>> listed under the project
>>> downloads page.
>> Take a look here:
>> http://layers.openembedded.org/layerindex/branch/master/layers this is
>> the "master" list of all the "known" layers, recipes, etc. As you can
>> see, there are quite a few BSP layers.
> Furthermore, you can click on the "Machines" tab i.e.
>
> http://layers.openembedded.org/layerindex/branch/master/machines/
>
> Type in a keyword (or leave the box empty to see all) and hit Search, and
> you'll see a list of the matching machines provided by all the layers in the
> index.
>
> Cheers,
> Paul
>
Trevor & Paul,
Ok, thanks much.  I'll dig into this more now.
By the way, the page that gave me the impression there were very
few BSPs is this: https://www.yoctoproject.org/downloads/bsps
Clicking on "Board Support Packages" and using <Any> and <ARM>
for "YP Core Release" and "Processor Family" respectively.

-- 
Ed Sutter
Alcatel-Lucent Technologies -- Bell Laboratories
Phone: 908-582-2351
Email: ed.sutter@alcatel-lucent.com

Getting started

[Rahul Radhakrishnan]

Hi. I’m new and I would like to contribute. Can someone please get me started?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Getting started

[Tom]

I've got an AKAI EIE and I'd like to get it working under alsa
I've been programming for a lot of years on lots of different things so 
can someone point me to how to get started?
Tom

Re: Getting started

[Clemens Ladisch]

Tom wrote:
> I've got an AKAI EIE and I'd like to get it working under alsa

Did you try the class compliant mode?


Regards,
Clemens

Getting Started

[Karan Dev]

hey, I am new here. I'd like to contribute to your organisation. Could
someone guide me along ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130730/60f31c8f/attachment.html 

Getting Started

[Valdis.Kletnieks at vt.edu]

On Tue, 30 Jul 2013 23:03:24 +0530, Karan Dev said:

> hey, I am new here. I'd like to contribute to your organisation. Could
> someone guide me along ?

We could give you more guidance if we understood *why* you want to
contribute.  Different people help for different reasons - the advice
we give to somebody who has hardware that lacks a device driver will
be different from somebody who wants to do QA, and if you're an evangelist
at heart, there's yet another set of things you should concentrate on...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130730/f0cd0581/attachment.bin 

Getting Started

[Valdis.Kletnieks at vt.edu]

On Wed, 31 Jul 2013 10:32:59 +0530, you said:

> I am a computer science student. I want to contribute to the open source
> projects, debugging. As it is my first time, i need some guidance.

(a) You're better off replying to the list, as you then get answers from
others besides me.  Redirecting  back to the list.

(b) If you want to actually *help*, and have it set on being the kernel rather
than any one of thousands of deserving userspace projects, your best bet is

1) learn to build and install a self-compiled kernel.
2) just get a copy of the 'linux-next' tree
3) Update and build kernels every few days
4) watch them fail (and fail they will - I have at least 3 bugs I've tripped
over in the past week to report still)
5) Use 'git bisect' to identify the patch that caused the failure, and report
it to the appropriate people.

Quite frankly, the kernel needs less half-baked patches from novices, and more
qualified testers.  And you can get up to speed on testing a heck of a lot
faster than you can learn all the ins and outs of kernel code hacking.
And if you're ambitious, you can always add "(6) include a patch fixing
the problem" once you get better at it...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130731/67592174/attachment.bin 

Getting Started

[Sumeet pawnikar]

Hi Valdis,

Thanks for these steps,

On Wed, Jul 31, 2013 at 6:05 PM, <Valdis.Kletnieks@vt.edu> wrote:

> On Wed, 31 Jul 2013 10:32:59 +0530, you said:
>
> > I am a computer science student. I want to contribute to the open source
> > projects, debugging. As it is my first time, i need some guidance.
>
> (a) You're better off replying to the list, as you then get answers from
> others besides me.  Redirecting  back to the list.
>
> (b) If you want to actually *help*, and have it set on being the kernel
> rather
> than any one of thousands of deserving userspace projects, your best bet is
>
> 1) learn to build and install a self-compiled kernel.
> 2) just get a copy of the 'linux-next' tree
>

Do we need to git clone 'linux-next' tree or 'linus' tree ?


> 3) Update and build kernels every few days
> 4) watch them fail (and fail they will - I have at least 3 bugs I've
> tripped
> over in the past week to report still)
> 5) Use 'git bisect' to identify the patch that caused the failure, and
> report
> it to the appropriate people.
>
> Quite frankly, the kernel needs less half-baked patches from novices, and
> more
> qualified testers.  And you can get up to speed on testing a heck of a lot
> faster than you can learn all the ins and outs of kernel code hacking.
> And if you're ambitious, you can always add "(6) include a patch fixing
> the problem" once you get better at it...
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130805/5e0c77c7/attachment.html 

Getting Started

[anish singh]

On Aug 5, 2013 10:24 PM, "Sumeet pawnikar" <sumeet4linux@gmail.com> wrote:
>
> Hi Valdis,
>
> Thanks for these steps,
>
> On Wed, Jul 31, 2013 at 6:05 PM, <Valdis.Kletnieks@vt.edu> wrote:
>>
>> On Wed, 31 Jul 2013 10:32:59 +0530, you said:
>>
>> > I am a computer science student. I want to contribute to the open
source
>> > projects, debugging. As it is my first time, i need some guidance.
>>
>> (a) You're better off replying to the list, as you then get answers from
>> others besides me.  Redirecting  back to the list.
>>
>> (b) If you want to actually *help*, and have it set on being the kernel
rather
>> than any one of thousands of deserving userspace projects, your best bet
is
>>
>> 1) learn to build and install a self-compiled kernel.
>> 2) just get a copy of the 'linux-next' tree
>
>
> Do we need to git clone 'linux-next' tree or 'linus' tree ?
Linux next for submitting patches
>
>>
>> 3) Update and build kernels every few days
>> 4) watch them fail (and fail they will - I have at least 3 bugs I've
tripped
>> over in the past week to report still)
>> 5) Use 'git bisect' to identify the patch that caused the failure, and
report
>> it to the appropriate people.
>>
>> Quite frankly, the kernel needs less half-baked patches from novices,
and more
>> qualified testers.  And you can get up to speed on testing a heck of a
lot
>> faster than you can learn all the ins and outs of kernel code hacking.
>> And if you're ambitious, you can always add "(6) include a patch fixing
>> the problem" once you get better at it...
>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130805/7ad42851/attachment.html 

Getting Started

[Valdis.Kletnieks at vt.edu]

On Mon, 05 Aug 2013 22:14:25 +0530, Sumeet pawnikar said:

> Do we need to git clone 'linux-next' tree or 'linus' tree ?

Cloning Linus's tree works.  Cloning linux-next won't do what you think it does.

You want to do something like this to grow your own copy of linux-next:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ git remote add linux-next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
$ git fetch linux-next
$ git fetch --tags linux-next

After which, using 'git remote update' will refresh it. Do *NOT*, repeat *NOT*
try to use 'git pull', because this isn't a clone that you can pull onto...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130805/9a8c8bf8/attachment.bin 

Re: Getting Started

[Steve Burtchin]

On Wed, 09 May 2012 15:09:27 +0200 Vladimir '?-coder/phcoder' Serbinenko
wrote:
> > I am still free to install GRUB2 to the partition boot sector of any
distro
> > which demands it, and chainload GRUB2 from GRUB Legacy or any other boot
> > loader I choose.
> Make sure that you understand the insecurity and unreliability of this
> config (blocklist issue).
Thanks for the reminder.  GRUB2 in compatible config should have its own
dedicated partition intentionally kept static, else it likely would become
unpredictably broken.
> > Regards
> > Stephen Burtchin
> >
> -- 
> Regards
> Vladimir '?-coder/phcoder' Serbinenko
>
Regards
Stephen Burtchin

Re: Getting Started

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

On 10.05.2012 08:28, Steve Burtchin wrote:
> On Wed, 09 May 2012 15:09:27 +0200 Vladimir '?-coder/phcoder' Serbinenko
> wrote:
>>> I am still free to install GRUB2 to the partition boot sector of any
> distro
>>> which demands it, and chainload GRUB2 from GRUB Legacy or any other boot
>>> loader I choose.
>> Make sure that you understand the insecurity and unreliability of this
>> config (blocklist issue).
> Thanks for the reminder.  GRUB2 in compatible config should have its own
> dedicated partition intentionally kept static, else it likely would become
> unpredictably broken.
I will answer any of your emails only when you're interested in real
discussion, not exchange of provocations.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Getting Started

[Steve Burtchin]

On Mon, 07 May 2012 22:25:21 +0200 Vladimir '?-coder/phcoder' Serbinenko
wrote:
> On 02.05.2012 06:27, Steve Burtchin wrote:
> > Assuming such support is added, this would allow for a few or more
> > specialized logical partitions that could have shared usage between the
> > GPT-unaware OSs.
> The only difficulty with creating logical partition is a need to have
> some space before partition for pointer. This can be encapsulated into a
> GPT partition of newly defined type. Having same partitions in GPT and
> as logical is of no problem otherwise. parted and gpart can be extended
> to offer creating such buffers when requested.
> . . . in the light of recent developpement
> it's preffered to use GPT for "permanent storage".
I shall set-up a test machine with GPT partitioned disk including extended
parition to see what trade-offs might be needed compared to my current
practice before arguing this point (MBR partitioning) further.  In theory,
two primaries + extended should always be sufficient for any GPT-unaware OS.

> > have my concerns for leaving the protective MBR in a pseudo-random
> > hybrid state (that is determined by the most recent boot configuration)
to
> > be seen by utilities or OS's that may think something is amiss and then
try
> > to fix.
> It applies to all kind of MBR workarounds
Your point is well taken.  In practice I only use naturally occuring
partition configurations (which usually includes some "apparent" free
space).  With capacity to mess with partition tables, another user may
create any kind of wierd partitioning arrangement.

> > If it is the vision for GRUB2 to support an extended partition in the
hybrid
> > MBR, then in my humble opinion the ability to edit an EBR at boot time
would
> > be a desirable feature.  If one wants to share such an extended
partition
> > between LBA-aware and LBA-unaware OSs, then it is an essential feature
IMO.
> Some features are usable but are a recipe for a disaster in long term
> like e.g. if you move your partitions and forget to change numbers in
> config file. This is like asking people to locate their files by sectors
> or enter the programs in hex manually. Such arrangements should be
> discouraged when better ones are available.
The analogy of "locating files by sector" is a good one.  I will agree with
that, and that changing numbers in a config file is prone to error.  In
defining a truncated extended partition for the LBA-unaware OSs, these are
mostly old and have well understood space requirements.  In practice I never
found the need to move this transition point.  Skipping over some logicals
(to keep Windows from going nuts) on my disk with 39 partitions was a bit
trickier.  The typical worst case after resizing some logicals was that GRUB
Legacy could not find where to write the revised EBR (the "55AAh" wasn't
found, so nothing was written) or wrote an EBR pointing to the wrong sector.
Any user knowing enough of partition tables to mess with the EBRs in the
first place should immediately recognize the problem when half the extended
partition disappears.  However, I will experiment with the possibilities of
creating alternate extended partitions on a GPT disk before arguing this
point further.

> > By limiting GRUB2 support to GPT disks for users wanting more than 4
> > primary partitions, you are forcing them to migrate to GPT partitioning
> > even if they are not running any GPT-aware OSs or have no other reasons
> > to migrate.
> Nobody is forcing anyone to this.
> . . .
> Argument "implement this or you deprive me of my freedom" is an old
> trick and it's not how free software works
"Coercing" would have been a better choice of words, but I see you point.  I
am still free to install GRUB2 to the partition boot sector of any distro
which demands it, and chainload GRUB2 from GRUB Legacy or any other boot
loader I choose.

Regards
Stephen Burtchin

Re: Getting Started

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]


> "Coercing" would have been a better choice of words, but I see you point.  I
> am still free to install GRUB2 to the partition boot sector of any distro
> which demands it, and chainload GRUB2 from GRUB Legacy or any other boot
> loader I choose.
Make sure that you understand the insecurity and unreliability of this
config (blocklist issue).
> Regards
> Stephen Burtchin
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Getting Started

[Steve Burtchin]

On Fri, 13 Apr 2012 12:04:26 +0200 Vladimir '?-coder/phcoder' Serbinenko
wrote:
> On 13.04.2012 11:39, Steve Burtchin wrote:
> > On Tue, 10 Apr 2012 14:26:54 +0200 Vladimir '?-coder/phcoder'
> > Serbinenko wrote:
> > >On 10.04.2012 12:56, Steve Burtchin wrote:
> > >> I found the URL to the bug report.  It is
> > >> http://savannah.gnu.org/bugs/?19410.  In summary (and more
> > >> specifically), I wish to add the following features to the GRUB2
> > >> 'parttool' command:
> > >>
> > >> 1) Create or delete a primary partition.  This functionality was
> > >> provided by the 'partnew' command in GRUB Legacy.  See also
> > >> http://savannah.gnu.org/bugs/?19389.

> > I was using the terminology from the GRUB legacy manual:
> > "partnew . . . Create a new primary partition."  IMHO this would be
> > more appropriately described as "Edit a slot in the MPT
> Please stop inventing your own shortcuts, it makes it difficult to read
> and understand you.
Please accept my appologies.  These shortcuts are frequently used on many
computing forums, but I should not have assumed that they were being used
here.  I shall refrain from their use in the future.  For the reference of
anyone following this thread:
IMHO - In My Humble Opinion (although "IMO" has been used here - ref: Vol
98, Issue 18)
MHO - My Humble Opinion
JMHO - Just My Humble Opinion
MPT - Master Partition Table (widespread usage)
"slot in MPT" = "master partition table entry"
wrt. - with respect to
EPBR = PBR - Extended Partition Boot Record (widespread usage)
HDD - Hard Disk Drive
EPT - Extended Partition Table (same as PBR) (PowerQuest terminology - not
in widespread use)
AFAIK - As Far As I Know

> > (to define an alternate primary partition)."  The corresponding
> > terminology ("delete") would IMHO be more appropriately described as
> > "Zero a slot in the MPT (to thoroughly hide a primary partition from
> > aggressive installers)."  For example, suppose I want to install
> > WindowsXP to hda3.  The safest approach would be to create a menuitem
> > in grub.cfg to zero out slots 1, 2 & 4 of the MPT, and then boot the
> > CD.  The installer then only sees one partition with the rest being
> > free space, for which it will ask you before overwriting it.
> Not true. Some installers take free space to silently create some
> partitions it believes should be "always present". Moreover most of
> concerned OS ignore partitions with unknown type so just setting hidden
> flag is enough.
I am sure you are far more knowledgeable in regards to installers than I am.
I have personally been the victum of aggressive installers messing with
defined partitions, and I have read the horror stories of many others, but I
should not have assumed the converse situation was not also a problem.  In
the future, when in doubt, I will leave the partition definitions in place
(when installing OSs).  And of course, always have everything backed-up.
Thank you for this information.

Now that you have pointed this out, would it not be true that except in two
special cases {that is: where the three partitions (other than the '0xEE')
defined
in the hybrid protective MBR are either (physically) the first three or last
three
on the disk} the installer of any GPT-unaware OS would always perceive
there to be some free space on the disk?  {this assumes 'gptsync' modifies
the hybrid MBR in an intelligent way (explained next paragraph)}  It is
beyond my expertise to say
if this is a problem, but as you pointed out, some installers may silently
use any area they believe to be free space.

If the hybrid MBR is modified in an intelligent way by 'gptsync', IMO the
partition of type '0xEE' would ideally span as much of
the space as possible not included in the other three primary partition
entries.  With 'gptsync' as it is described in the GRUB2 manual, what is not
clear to me is how (or if) this entry is kept consistent.  Migrating the
GRUB Legacy
'partnew' functionality to GRUB2 would provide one possibility for dealing
with this issue.

What is worse IMO is an inconsistent hybrid MBR where the '0xEE' entry spans
the entire disk and overlaps the other three entries.  This is the
implication as 'gptsync' is described.  Any unsuspecting user may try to use
a utility that automatically "fixes" something it thinks is amiss.

> >
> >  the intended use of my
> > proposed new functionality (wrt. item 1) would be esentially identical
> > to that of the 'gptsync' command, the only difference being that the
> > source of the MPT data would reside in 'menu.cfg' rather than in the
> > GPT partition entries.
> You need partition table in the first place in order to access grub.cfg
> (and it's not menu.cfg).
In my haste I was conflating GRUB Legacy with GRUB2.  My sincere apologies.

Thank you for pointing this out.  In my case, I have a small FAT partition
at the beginning of the disk containing all the GRUB Legacy files.  This
partition (by necessity) remains defined in all boot configurations.  One
would never want
to delete the partition (table entry) containing 'grub.cfg', else GRUB2
would not be able to find it on the subsequent
boot.  The other partition table entries may be changed as appropriate.

I also have GRUB Legacy
installed to a floppy with a special 'menu.lst' residing on
the floppy that can be used to restore the partition
tables in the event of a disaster.  IMO this functionality (not currently in
GRUB2) is a valuable (and safe) asset for recovery if ever the partition
tables get corupted.

> > >>
> > >> 2) Edit extended partition tables (EPBRs).  This functionality was
> > >> added to GRUB Legacy with the 'eptedit' command as described in bug
> > >> report #19410.
> > >>
> > > I feel like improvements into our gptsync (i.a. support for creating
> > > secondary partitions when possible) solves the same problems (having
> > > more than 4 OS requiring primary partitions) but in a more
standartised
> > > way and with a benefit of that GPT-aware tools will handle the whole
> > > thing correctly.
> >
> > It is entirely true that with a GPT partitioned disk and 'gptsync' one
> > could setup GRUB2 to boot more than 100 GPT-unaware operating systems
> > each requiring its own primary partition to boot.  However, in
> > practice this is severly restrictive in the great majority of
> > computers sold for home use (and business workstation computers) which
> > have only one HDD.  With only one HDD, this leaves only two other
> > partitions for sharing and storing data for GPT-unaware OSs.
> As I said: I'd rather add a support for creating extended partitions in
> protective MBR.
Assuming such support is added, this would allow for a few or more
specialized logical partitions that could have shared usage between the
GPT-unaware OSs.  However, this extended partition would not be usable by
any GPT-aware OS unless each logical partition has a duplicate definition in
the GPT.  It is beyond my expertise to say if this is practical or supported
by any partitioning software.

I was unaware any partitioning tool supported this (ie. creating an extended
partition in the protective MBR), and still not convinced such a hybrid
state would be safe for unsuspecting users (ref:
http://www.rodsbooks.com/gdisk/hybrid.html).  I do not have first hand
knowledge to say if this is a potential problem,
but quoting from the referenced link: "There's no telling how some random
disk utility will react to a hybrid MBR; it's conceivable that something
intended to rescue your data will end up destroying it." (Rod Smith).

Except as just stated, I have no concerns with using such a partitioning
scheme, but have my
concerns for leaving the protective MBR in a pseudo-random hybrid state
(that is determined by the most recent boot configuration) to
be seen by utilities or OS's that may think something is amiss and then try
to fix.

If it is the vision for GRUB2 to support an extended partition in the hybrid
MBR, then in my humble opinion the ability to edit an EBR at boot time would
be a desirable feature.  If one wants to share such an extended partition
between LBA-aware and LBA-unaware OSs, then it is an essential feature IMO.

You cut off reading my previous message at this point.  I know that I made
some false assumptions, but I would only hope that you would
reconsider my previous message in its totality.

As I stated in my previous message: "in a single disk system, and in systems
where the second HDD is > 2TB, it is MHO (my humble opinion) that the
superior arrangement would be to have the first HDD (hard disk drive) MBR
partitioned.  In these systems (the greater majority in existence today)
this provides the greatest amount of flexibility in terms of the quantity of
common partitions available to all GPT-unaware and GPT-aware OSs (and
GPT-unaware imaging tools)."

#########################################################

The GNU Project defines free software as having four essential freedoms.  In
'The Free Software Definition' (ref:
http://www.gnu.org/philosophy/free-sw.html) 'freedom 0' is defined as "The
freedom to run the program, for any purpose".  This is further clarified as
follows:

"The freedom to run the program means the freedom for any kind of person or
organization to use it on any kind of computer system, for any kind of
overall job and purpose, . . .  In this freedom, it is the user's purpose
that matters, not the developer's purpose; you as a user are free to run the
program for your purposes, and if you distribute it to someone else, she is
then free to run it for her purposes, but you are not entitled to impose
your purposes on her."

By limiting GRUB2 support to GPT
disks for users wanting more than 4 primary partitions, you are forcing them
to migrate to GPT partitioning even if they are not running any GPT-aware
OSs or have no other reasons to migrate.  You are also denying these users
the right to choose when to abandon use of their favorite partitioning,
imaging, and other utilities.  In essence the 'developer's purpose' is being
imposed on some users of GRUB2, forcing them to make changes in the way they
do their partitioning, imaging, data management, etc.  It is understandable
that in the release of a new software product, it may not initially contain
every feature a user may want or need, and the development team may have to
prioritize its resources.  However, when an outsider such as myself is
willing to donate support for configurations still in widespread usage, and
such support is mandated by your own stated philosophy, I do not understand
why you would not accept the offer.

> -- 
> Regards
> Vladimir '?-coder/phcoder' Serbinenko

Cordially
Stephen Burtchin

Re: Getting Started

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 3651 bytes --]

On 02.05.2012 06:27, Steve Burtchin wrote:
> Assuming such support is added, this would allow for a few or more
> specialized logical partitions that could have shared usage between the
> GPT-unaware OSs.  However, this extended partition would not be usable by
> any GPT-aware OS unless each logical partition has a duplicate definition in
> the GPT.  It is beyond my expertise to say if this is practical or supported
> by any partitioning software.
The only difficulty with creating logical partition is a need to have
some space before partition for pointer. This can be encapsulated into a
GPT partition of newly defined type. Having same partitions in GPT and
as logical is of no problem otherwise. parted and gpart can be extended
to offer creating such buffers when requested.
Also a long time ago I wrote a tool which can be used to transform
between primary and logical partitions at will at GRUB time without any
need to type numbers manually but in the light of recent developpement
it's preffered to use GPT for "permanent storage".
> I was unaware any partitioning tool supported this (ie. creating an extended
> partition in the protective MBR), and still not convinced such a hybrid
> state would be safe for unsuspecting users (ref:
> http://www.rodsbooks.com/gdisk/hybrid.html).  I do not have first hand
> knowledge to say if this is a potential problem,
> but quoting from the referenced link: "There's no telling how some random
> disk utility will react to a hybrid MBR; it's conceivable that something
> intended to rescue your data will end up destroying it." (Rod Smith).

>
> Except as just stated, I have no concerns with using such a partitioning
> scheme, but have my
> concerns for leaving the protective MBR in a pseudo-random hybrid state
> (that is determined by the most recent boot configuration) to
> be seen by utilities or OS's that may think something is amiss and then try
> to fix.
It applies to all kind of MBR workarounds
> If it is the vision for GRUB2 to support an extended partition in the hybrid
> MBR, then in my humble opinion the ability to edit an EBR at boot time would
> be a desirable feature.  If one wants to share such an extended partition
> between LBA-aware and LBA-unaware OSs, then it is an essential feature IMO.
Some features are usable but are a recipe for a disaster in long term
like e.g. if you move your partitions and forget to change numbers in
config file. This is like asking people to locate their files by sectors
or enter the programs in hex manually. Such arrangements should be
discouraged when better ones are available.
> You cut off reading my previous message at this point.  I know that I made
> some false assumptions, but I would only hope that you would
> reconsider my previous message in its totality.
I won't. Your messages are way too long for the ideas you want to
transfer. Brevity and exactness are essential in such kind of conversations.
> By limiting GRUB2 support to GPT disks for users wanting more than 4
primary partitions, you are forcing them to migrate to GPT partitioning
even if they are not running any GPT-aware OSs or have no other reasons
to migrate.
Nobody is forcing anyone to this. You can modify yourself your own
system to your preferences. Or hire anyone to do this. Ad absurdum by
not putting a big red button on desktop which deletes all files you
deprive users of freedom to screw up by their stupidity.
Argument "implement this or you deprive me of my freedom" is an old
trick and it's not how free software works

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: RE: Re: Getting Started

[Steve Burtchin]

[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]

On Sun, 8 Apr 2012 03:50:18 -0400 Steve Burtchin worte:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>On Sat, 07 Apr 2012 13:17:15 +0200 Vladimir '?-coder/phcoder' Serbinenko wrote:
>------------------------------------------------------------------------------------
>On 07.04.2012 11:54, Steve Burtchin wrote:
>> GRUB Developers,
>>  
>> Please help me get started developing GRUB2.  I would like to add some
>> additional functionality to the 'parttool' command (functionally
>> similar to the code changes I proposed for GRUB-Legacy).
>Could you give more details?
>------------------------------------------------------------------------------------
>
>I had hoped I could answer the details question with a URL link, but I cannot find that
>bug report now.  
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I found the URL to the bug report.  It is http://savannah.gnu.org/bugs/?19410.  In summary (and more specifically), I wish to add the following features to the GRUB2 'parttool' command:

1) Create or delete a primary partition.  This functionality was provided by the 'partnew' command in GRUB Legacy.  See also http://savannah.gnu.org/bugs/?19389.

2) Edit extended partition tables (EPBRs).  This functionality was added to GRUB Legacy with the 'eptedit' command as described in bug report #19410.

NOTE: Not mentioned in the original bug report: with the ability to edit EPBRs, the potential number of logical partitions is limited only by the disk geometry for any SATA, PATA or SCSI disk.

Regards,

Steve Burtchin

[-- Attachment #2: Type: text/html, Size: 3012 bytes --]

Re: Getting Started

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]

On 10.04.2012 12:56, Steve Burtchin wrote:
> On Sun, 8 Apr 2012 03:50:18 -0400 Steve Burtchin worte:
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >On Sat, 07 Apr 2012 13:17:15 +0200 Vladimir '?-coder/phcoder'
> Serbinenko wrote:
> >------------------------------------------------------------------------------------
> >On 07.04.2012 11:54, Steve Burtchin wrote:
> >> GRUB Developers,
> >> 
> >> Please help me get started developing GRUB2.  I would like to add some
> >> additional functionality to the 'parttool' command (functionally
> >> similar to the code changes I proposed for GRUB-Legacy).
> >Could you give more details?
> >------------------------------------------------------------------------------------
> >
> >I had hoped I could answer the details question with a URL link, but
> I cannot find that
> >bug report now. 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  
> I found the URL to the bug report.  It is
> http://savannah.gnu.org/bugs/?19410.  In summary (and more
> specifically), I wish to add the following features to the GRUB2
> 'parttool' command:
>  
> 1) Create or delete a primary partition.  This functionality was
> provided by the 'partnew' command in GRUB Legacy.  See also
> http://savannah.gnu.org/bugs/?19389.
As I've explained in a parallel thread (the one concerning SoC), any
writing to disk is potentially dangerous and so we need a good reason to
do it. Why would you want to regularly create and destroy partitions in
GRUB?
>  
> 2) Edit extended partition tables (EPBRs).  This functionality was
> added to GRUB Legacy with the 'eptedit' command as described in bug
> report #19410.
>  
I feel like improvements into our gptsync (i.a. support for creating
secondary partitions when possible) solves the same problems (having
more than 4 OS requiring primary partitions) but in a more standartised
way and with a benefit of that GPT-aware tools will handle the whole
thing correctly.
> NOTE: Not mentioned in the original bug report: with the ability to
> edit EPBRs, the potential number of logical partitions is limited only
> by the disk geometry for any SATA, PATA or SCSI disk.
>  
> Regards,
>  
> Steve Burtchin
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Getting Started

[Steve Burtchin]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

GRUB Developers,

Please help me get started developing GRUB2.  I would like to add some additional functionality to the 'parttool' command (functionally similar to the code changes I proposed for GRUB-Legacy).  What can you tell me about how the new code is organized and what coding rules are in place.  Is there a structure chart showing the heirarchy of function calls?  Do you have specific recommendations for editors etc.  I am using Debian Linux.  I notice that the new code contains a lot of pre-processor directives.  Do you have specific recommendations about understanding and working on the code?

Thank you,

Stephen Burtchin

[-- Attachment #2: Type: text/html, Size: 1279 bytes --]

Re: Getting Started

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

On 07.04.2012 11:54, Steve Burtchin wrote:
> GRUB Developers,
>  
> Please help me get started developing GRUB2.  I would like to add some
> additional functionality to the 'parttool' command (functionally
> similar to the code changes I proposed for GRUB-Legacy).
Could you give more details?
> What can you tell me about how the new code is organized and what
> coding rules are in place.
We follow GCS (GNU Coding Standards) and we have a small manual
ourselves in docs/grub-dev.*
>   Is there a structure chart showing the heirarchy of function calls?
No
>   Do you have specific recommendations for editors etc.
emacs and indent with default setting
>   I am using Debian Linux.  I notice that the new code contains a lot
> of pre-processor directives.  Do you have specific recommendations
> about understanding and working on the code?
>
The preprocessor directive names should be explicit enough.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Getting Started

[Russell Morris]

Hi,

My apologies in advance for what is likely a stupid question, but I have been working with OpenEmbedded for a while, with some level of success (and some pain ... :-)), but it really seems that the current information on the Wiki site related to Getting Started (http://www.openembedded.org/wiki/Getting_started) is out of date.

I have checked out the git repository, and it really seems that the newer "core" and "meta" trees are being updated regularly (and not the old openembedded tree), but I'm not sure how to use them to get builds working. This is likely just ignorance on my part, but is there any info out there of how to work with the new structure?

Thanks in advance for any pointers that you have!

... Russell

Re: Getting Started

[Andreas Müller]

On Thursday, October 06, 2011 01:11:50 AM Russell Morris wrote:
> Hi,
> 
> My apologies in advance for what is likely a stupid question, but I have been working with OpenEmbedded for a while, with some level of success (and some pain ... :-)), but it really seems that the current information on the Wiki site related to Getting Started (http://www.openembedded.org/wiki/Getting_started) is out of date.
> 
> I have checked out the git repository, and it really seems that the newer "core" and "meta" trees are being updated regularly (and not the old openembedded tree), but I'm not sure how to use them to get builds working. This is likely just ignorance on my part, but is there any info out there of how to work with the new structure?
> 
> Thanks in advance for any pointers that you have!
> 
> ... Russell
> 
http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/angstrom-layers/tree/README
http://sakrah.homelinux.org/blog/2011/03/using-openembedded-core-to-build-angstrom-for-qemu/

Re: Getting Started

[Henning Heinold]

On Wed, Oct 05, 2011 at 06:11:50PM -0500, Russell Morris wrote:
> Hi,
> 
> My apologies in advance for what is likely a stupid question, but I have been working with OpenEmbedded for a while, with some level of success (and some pain ... :-)), but it really seems that the current information on the Wiki site related to Getting Started (http://www.openembedded.org/wiki/Getting_started) is out of date.
> 
> I have checked out the git repository, and it really seems that the newer "core" and "meta" trees are being updated regularly (and not the old openembedded tree), but I'm not sure how to use them to get builds working. This is likely just ignorance on my part, but is there any info out there of how to work with the new structure?
> 
> Thanks in advance for any pointers that you have!
> 
> ... Russell

Hi Russel,

oe-core is described here too

http://www.openembedded.org/wiki/Oe-core

Bye Henning

Re: Getting Started

[Russell Morris]

Thanks so much for the pointers folks - very much appreciated!
Take care,... Russell


On Thu, 10/06/2011 03:21 AM, Henning Heinold <heinold@inf.fu-berlin.de> wrote:
> On Wed, Oct 05, 2011 at 06:11:50PM -0500, Russell Morris wrote:
> > Hi,
> > 
> > My apologies in advance for what is likely a stupid question, but I have been working with OpenEmbedded for a while, with some level of success (and some pain ... :-)), but it really seems that the current information on the Wiki site related to Getting Started (http://www.openembedded.org/wiki/Getting_started) is out of date.
> > 
> > I have checked out the git repository, and it really seems that the newer "core" and "meta" trees are being updated regularly (and not the old openembedded tree), but I'm not sure how to use them to get builds working. This is likely just ignorance on my part, but is there any info out there of how to work with the new structure?
> > 
> > Thanks in advance for any pointers that you have!
> > 
> > ... Russell
> 
> Hi Russel,
> 
> oe-core is described here too
> 
> http://www.openembedded.org/wiki/Oe-core
> 
> Bye Henning
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
From ulf_samuelsson@telia.com Mon Oct 10 23:59:11 2011
Received: from smtprelay-h22.telenor.se ([195.54.99.197])
	by linuxtogo.org with esmtp (Exim 4.72)
	(envelope-from <ulf_samuelsson@telia.com>) id 1RDNsM-0007m5-NH
	for openembedded-devel@lists.openembedded.org;
	Mon, 10 Oct 2011 23:59:10 +0200
Received: from iph3.telenor.se (iph3.telenor.se [195.54.127.134])
	by smtprelay-h22.telenor.se (Postfix) with ESMTP id 9B06AEAF59
	for <openembedded-devel@lists.openembedded.org>;
	Mon, 10 Oct 2011 23:29:24 +0200 (CEST)
X-SENDER-IP: [83.227.57.13]
X-LISTENER: [smtp.bredband.net]
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApguANZik05T4zkNPGdsb2JhbAAMN4k8kASOfgEBAQE3gkRAPRYYAwIBAgExJwgBAcFQh0MEk3eRVA
X-IronPort-AV: E

getting started

[Littlefield, Tyler]

Hello all:
I'd like to get going working on the kernel (I've tried getting started 
the last few times).
On the kernelnewbies page, one of the kernel janitor projects is to 
balance out functions and clean up code. I'm curious if there would be 
someone, or a group of someone's who would mind assigning me a specific 
file or a small driver of some sort that needs this so I can get started 
helping out?

-- 

Take care,
Ty
my website:
http://tds-solutions.net
my blog:
http://tds-solutions.net/blog
skype: st8amnd127
My programs don't have bugs; they're randomly added features!

getting started

[Vladimir Murzin]

On Fri, Aug 19, 2011 at 5:26 AM, Littlefield, Tyler <tyler@tysdomain.com> wrote:
> Hello all:
> I'd like to get going working on the kernel (I've tried getting started
> the last few times).
> On the kernelnewbies page, one of the kernel janitor projects is to
> balance out functions and clean up code. I'm curious if there would be
> someone, or a group of someone's who would mind assigning me a specific
> file or a small driver of some sort that needs this so I can get started
> helping out?
>
> --
>
> Take care,
> Ty
> my website:
> http://tds-solutions.net
> my blog:
> http://tds-solutions.net/blog
> skype: st8amnd127
> My programs don't have bugs; they're randomly added features!
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

Hi Tyler!

Have you read FAQ/WhereDoIBegin [1] and kernel-janitors TODO list [2]?

[1] http://kernelnewbies.org/FAQ/WhereDoIBegin
[2] http://code.google.com/p/kernel-janitors/wiki/TODO

getting started

[Julie Sullivan]

Hi Tyler

You can also get ideas from sitting on the mailing list and seeing
what others are doing:
kernel-janitors.vger.kernel.org
(kernel-janitors at vger.kernel.org)

Also driver staging is always looking for more contributors and you
can get a good feel for what is going on on the mailing list:
devel.linuxdriverproject.org
(devel at linuxdriverproject.org)

Read the TODO lists for various drivers in the in the kernel tree in
drivers/staging/ and pick something you would like to do. Don't forget
to read the relevant files in Documentation/ for preparing/submitting
patches, etc, and make sure you cc the relevant maintainers when
sending patches to their drivers to the list.

If you're not doing it already by far the easiest way is to use git to
manage your kernels, you will be expected to test your patches against
linux-next or some branch specified by a particular maintainer which
you can remote track (I think it's staging-next on Greg's tree for
staging, but it wouldn't hurt to ask the maintainer once you have the
patch ready).

Cheers
Julie

getting started

[Julie Sullivan]

> Also driver staging is always looking for more contributors and you
> can get a good feel for what is going on on the mailing list:
> devel.linuxdriverproject.org
> (devel at linuxdriverproject.org)
>
> Read the TODO lists for various drivers in the in the kernel tree in
> drivers/staging/ and pick something you would like to do. Don't forget
> to read the relevant files in Documentation/ for preparing/submitting
> patches, etc, and make sure you cc the relevant maintainers when
> sending patches to their drivers to the list.
>
> If you're not doing it already by far the easiest way is to use git to
> manage your kernels, you will be expected to test your patches against
> linux-next or some branch specified by a particular maintainer which
> you can remote track (I think it's staging-next on Greg's tree for
> staging, but it wouldn't hurt to ask the maintainer once you have the
> patch ready).
>
> Cheers
> Julie
>

Oh, and another suggestion - find out what hardware you have and find
out what corresponding drivers cater for it in the kernel. You can
then join the appropriate mailing lists (filtering on their throughput
if it's large) in order to catch any new patches or bugs that appear
there for your hardware. You can then work on testing the
patches/helping fix the bugs, which is especially helpful when done by
people who have the actual hardware to test with. If it's new stuff in
staging, I think the staging people would particularly appreciate
this.

Cheers
Julie

getting started

[esmaeil mirzaee]

Hi

On Fri, Aug 19, 2011 at 11:44 PM, Julie Sullivan
<kernelmail.jms@gmail.com> wrote:
>> Also driver staging is always looking for more contributors and you
>> can get a good feel for what is going on on the mailing list:
>> devel.linuxdriverproject.org
This link is unavailable.
>> (devel at linuxdriverproject.org)
>>
>> Read the TODO lists for various drivers in the in the kernel tree in
>> drivers/staging/ and pick something you would like to do. Don't forget
>> to read the relevant files in Documentation/ for preparing/submitting
>> patches, etc, and make sure you cc the relevant maintainers when
>> sending patches to their drivers to the list.
>>
>> If you're not doing it already by far the easiest way is to use git to
>> manage your kernels, you will be expected to test your patches against
>> linux-next or some branch specified by a particular maintainer which
>> you can remote track (I think it's staging-next on Greg's tree for
>> staging, but it wouldn't hurt to ask the maintainer once you have the
>> patch ready).
>>
>> Cheers
>> Julie
>>
>
> Oh, and another suggestion - find out what hardware you have and find
> out what corresponding drivers cater for it in the kernel. You can
> then join the appropriate mailing lists (filtering on their throughput
> if it's large) in order to catch any new patches or bugs that appear
> there for your hardware. You can then work on testing the
> patches/helping fix the bugs, which is especially helpful when done by
> people who have the actual hardware to test with. If it's new stuff in
> staging, I think the staging people would particularly appreciate
> this.
>
> Cheers
> Julie
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

getting started

[Julie Sullivan]

On Sat, Aug 20, 2011 at 4:04 AM, esmaeil mirzaee
<esmaeil.debian@gmail.com> wrote:
> Hi
>
> On Fri, Aug 19, 2011 at 11:44 PM, Julie Sullivan
> <kernelmail.jms@gmail.com> wrote:
>>> Also driver staging is always looking for more contributors and you
>>> can get a good feel for what is going on on the mailing list:
>>> devel.linuxdriverproject.org
> This link is unavailable.

That's because it's a mailing list not a 'proper' link. You can subscribe here:

http://driverdev.linuxdriverproject.org/mailman/listinfo/devel

and you can subscribe to the kernel-janitors.vger.kernel.org one
(amongst many others) here:

http://vger.kernel.org/vger-lists.html

HTH,
Julie

Getting started

[hiren panchasara]

Hi all,

I want to start working on kernel development and as per everyone's
guidance I am starting with Janitor project. I am not able to
understand the TODO list on the janitor project site.

It would be great if someone can explain me how to get started and
actually work on something.

thanks,
/H

Re: Getting started

[Frederic Weisbecker]

On Tue, Jun 02, 2009 at 04:36:24PM -0700, hiren panchasara wrote:
> Hi all,
> 
> I want to start working on kernel development and as per everyone's
> guidance I am starting with Janitor project. I am not able to
> understand the TODO list on the janitor project site.
> 
> It would be great if someone can explain me how to get started and
> actually work on something.


I'm not sure whether kernel-janitor is a good start.
I might be wrong though.

Actually what I would suggest to you is to involve in a subsystem
in which you are attracted.

A good thing to do is to lurk on bug reports, trying to find the
problems, applying fixes proposed and testing them, trying to fix
it yourself.

Another thing, may be one of the best: most of the subsystems have
people working on experimental projects.

Look at this page on the bottom:

http://lwn.net/Kernel/

(Section Recent kernel patches)

Here you'll find some fresh meat. Start by testing patches
from these experimental branches, report the bugs you
see (you will often see a good batch of bugs), see how they
are fixed. Try also to fix them yourself. And continue on
this process. Try also to help developing enhancements on these
projects. You might start walking on these floors as a blind
man in the beginning but it will become more clear by the time.
Also subscribe to linux kernel mailing list (and specific mailing
lists for the project you involve in) so that you can follow the
hot topics.

There are no secrets, just do it.


 
> thanks,
> /H
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Getting started

[Charles 'Mack' Rhinelander]

I'm in a similar situation, I started kernel hacking a couple of weeks
ago.  I'm not much of a C programmer, and I've found the
kernelnewbies.org/FAQ section useful, particularly
kernelnewbies.org/FAQ/WhereDoIBegin That page describes lots of useful
things you can do just by compiling and running the kernel. I've
already submitted my first bug, a small thing in a makefile that kept
the -mm branch from compiling!

Mack Rhinelander

On 6/2/09, hiren panchasara <hiren.panchasara@gmail.com> wrote:
> Hi all,
>
> I want to start working on kernel development and as per everyone's
> guidance I am starting with Janitor project. I am not able to
> understand the TODO list on the janitor project site.
>
> It would be great if someone can explain me how to get started and
> actually work on something.
>
> thanks,
> /H
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Getting started

[Kevin DuBois]

hiren panchasara wrote:
> Hi all,
>
> I want to start working on kernel development and as per everyone's
> guidance I am starting with Janitor project. I am not able to
> understand the TODO list on the janitor project site.
>
> It would be great if someone can explain me how to get started and
> actually work on something.
>
>   
This is just general advice, but like I've found with adopting any new 
open source project (or any large codebase for that matter) the only 
_real_ way to make progress is to sit down at your computer with a lot 
of determination, and "bang your head against the wall" for a little 
bit. It always helps to have a clearly defined goal, like "make a driver 
work" or "implement this new algorithm". Every new project I've taken on 
has been like this, and kernel development is no different. "Just do it" 
is a lot easier said than done :D

It also helps to have a good grasp of operating systems concepts (about 
the level an undergrad OS course will give you) before starting. Usually 
people on the right IRC channels, or on mailing lists are very helpful, 
especially once they see you put some pseudo-useful code down.
> thanks,
> /H
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   
Kevin DuBois
kdub432@gmail.com

getting started

[Rolf Schumacher]

make in v4l-dvb worked without error, produced a lot of .ko files in v4l.
sudo make install worked without errors, too.

reconnecting the TechnoTrend CT 3650 CI, with dmesg I got

---
usb 4-2: USB disconnect, address 3
usb 4-2: new high speed USB device using ehci_hcd and address 6
usb 4-2: configuration #1 chosen from 1 choice
usb 4-2: New USB device found, idVendor=0b48, idProduct=300d
usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 4-2: Product: TT-USB2.0
usb 4-2: Manufacturer: TechnoTrend
usb 4-2: SerialNumber: LHKAMG
---

and thought, dvb_usb_ttusb2 would be the driver to load.

However, neither /dev/dvb0 nor /dev/video0 appeared following "sudo
modprobe dvb_usb_ttusb2".
Restart of linux did not help and did not reload dvb_usb_ttusb2.

I know it worked once but forgot, how.
And it seems that it works with some others:

http://www.linuxtv.org/pipermail/linux-dvb/2008-August/027804.html

How to determine what driver I need?
Do I need firmware?

Rolf

getting started

[Rolf Schumacher]

make in v4l-dvb worked without error, produced a lot of .ko files in v4l.
sudo make install worked without errors, too.

reconnecting the TechnoTrend CT 3650 CI, with dmesg I got

---
usb 4-2: USB disconnect, address 3
usb 4-2: new high speed USB device using ehci_hcd and address 6
usb 4-2: configuration #1 chosen from 1 choice
usb 4-2: New USB device found, idVendor=0b48, idProduct=300d
usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 4-2: Product: TT-USB2.0
usb 4-2: Manufacturer: TechnoTrend
usb 4-2: SerialNumber: LHKAMG
---

and thought, dvb_usb_ttusb2 would be the driver to load.

However, neither /dev/dvb0 nor /dev/video0 appeared following "sudo
modprobe dvb_usb_ttusb2".
Restart of linux did not help and did not reload dvb_usb_ttusb2.

I know it worked once but forgot, how.
And it seems that it works with some others:

http://www.linuxtv.org/pipermail/linux-dvb/2008-August/027804.html

How to determine what driver I need?
Do I need firmware?

Rolf

Getting Started

[Neshama Parhoti]

Hi all,

I'm about to write a new driver for mac80211.

Alas I'm not familiar with wireless basic concepts.

I have read everything in http://www.linuxwireless.org/
but I don't think that's enough.

Can you please point me to known good knowledge
references/overviews/tutorials on the subject ?

Thank You !!
Neshama

Re: Getting Started

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 349 bytes --]

Hi,

> Can you please point me to known good knowledge
> references/overviews/tutorials on the subject ?

The best can currently offer is
 (a) checking http://johannes.sipsolutions.net/files/mac80211/
 (b) reading include/net/mac80211.h
 (c) comparing to an existing driver, for example b43's main.c
 (d) asking questions here

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Getting Started

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 205 bytes --]


>  (a) checking http://johannes.sipsolutions.net/files/mac80211/

Mind you, that is outdated because of recent work in mac80211, there are
no more hw modes and BSS config was introduced.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Getting Started

[Neshama Parhoti]

Hi Johannes,

On Feb 7, 2008 3:26 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> Hi,
>
> > Can you please point me to known good knowledge
> > references/overviews/tutorials on the subject ?
>
> The best can currently offer is
>  (a) checking http://johannes.sipsolutions.net/files/mac80211/
>  (b) reading include/net/mac80211.h
>  (c) comparing to an existing driver, for example b43's main.c
>  (d) asking questions here

Those are great, thanks !!

Any idea where I can find an updated, general, panoramic introduction for
the wireless subject and terms (without having to delve into the specs
themselves..) ?
I guess I ought to understand basic concepts before delving into the actual
code and interfaces.

Again thank you for the help, it is much appreciated.

Neshama.
>
> johannes
>

Re: Getting Started

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]


> Any idea where I can find an updated, general, panoramic introduction for
> the wireless subject and terms (without having to delve into the specs
> themselves..) ?

Not really. Some stuff is on linuxwireless.org but you said you read
that already :) I'm sure there are books like "An introduction to
802.11" or so but I never read any so I can't recommend anything.

> I guess I ought to understand basic concepts before delving into the actual
> code and interfaces.

That is probably a good idea, yes.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Getting Started

[Neshama Parhoti]

On Feb 7, 2008 3:35 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>
> > Any idea where I can find an updated, general, panoramic introduction for
> > the wireless subject and terms (without having to delve into the specs
> > themselves..) ?
>
> Not really. Some stuff is on linuxwireless.org but you said you read
> that already :) I'm sure there are books like "An introduction to
> 802.11" or so but I never read any so I can't recommend anything.

No time either to order and read a book. I was really looking for whitepapars,
HOWTOs, tutorials and such. But all I can find is very outdated stuff,
from years back..

>
> > I guess I ought to understand basic concepts before delving into the actual
> > code and interfaces.
>
> That is probably a good idea, yes.
>
> johannes
>

Re: Getting Started

[Holger Schurig]

> Can you please point me to known good knowledge
> references/overviews/tutorials on the subject ?

Get a linux kernel via git. Look at the drivers in 
drivers/net/wireless. Some of them use mac80211, you can find 
out which one by looking at Kconfig there, e.g. when they have a 
line "depends on MAC80211" there.

Those existing drivers should be a great inspiration to you :-)


It also helps when you share more about your incentives. E.g. 
writing 

> I'm about to write a new driver for mac80211.

doesn't give a great deal of insight into what you're up to. 
Maybe someone else already begin to write a driver for your 
hardware ?!?!  No one can tell you this right now, so you can't 
possibly save work on your side.

For example, the openmoko people are writing a mac80211 driver 
for ar6k. Not every driver is already in the wireless-2.6 git 
tree.

Re: Getting Started

[Neshama Parhoti]

Hi Holger,

On Feb 7, 2008 3:35 PM, Holger Schurig <hs4233@mail.mn-solutions.de> wrote:
> > Can you please point me to known good knowledge
> > references/overviews/tutorials on the subject ?
>
> Get a linux kernel via git. Look at the drivers in
> drivers/net/wireless. Some of them use mac80211, you can find
> out which one by looking at Kconfig there, e.g. when they have a
> line "depends on MAC80211" there.

Ok, thanks.

> It also helps when you share more about your incentives.

Currently I'm only studying the subject, so no specific hardware,
I will probably write preliminary driver just for education, so I don't
care if someone is working on it now.

Re: Getting Started

[Holger Schurig]

> Currently I'm only studying the subject, so no specific
> hardware, I will probably write preliminary driver just for
> education, so I don't care if someone is working on it now.

In that case you can fill the (documentation) gap. Maybe it would 
even be fun to, e.g., write a "How I mastered to write a 
mac80211 driver" blog and post that.

Re: Getting Started

[Nick Kossifidis]

> For example, the openmoko people are writing a mac80211 driver
> for ar6k. Not every driver is already in the wireless-2.6 git
> tree.

[OT]

As far as i know Atheros released a GPLed driver along with their SDIO stack.
http://sourceforge.net/projects/sdio-linux/

Do you have a plan to include this in kernel ? What's the status ?

-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Re: Getting Started

[Dan Williams]

On Thu, 2008-02-07 at 17:04 +0200, Nick Kossifidis wrote:
> > For example, the openmoko people are writing a mac80211 driver
> > for ar6k. Not every driver is already in the wireless-2.6 git
> > tree.
> 
> [OT]
> 
> As far as i know Atheros released a GPLed driver along with their SDIO stack.
> http://sourceforge.net/projects/sdio-linux/
> 
> Do you have a plan to include this in kernel ? What's the status ?

2.6.24 already has an SDIO stack; hence the Atheros one is redundant.
The openmoko people already have a port of their ar6k driver to the
in-kernel SDIO stack.

Dan

Re: Getting Started

[Dan Williams]

On Thu, 2008-02-07 at 11:09 -0500, Dan Williams wrote:
> On Thu, 2008-02-07 at 17:04 +0200, Nick Kossifidis wrote:
> > > For example, the openmoko people are writing a mac80211 driver
> > > for ar6k. Not every driver is already in the wireless-2.6 git
> > > tree.
> > 
> > [OT]
> > 
> > As far as i know Atheros released a GPLed driver along with their SDIO stack.
> > http://sourceforge.net/projects/sdio-linux/
> > 
> > Do you have a plan to include this in kernel ? What's the status ?
> 
> 2.6.24 already has an SDIO stack; hence the Atheros one is redundant.
> The openmoko people already have a port of their ar6k driver to the
> in-kernel SDIO stack.

Which of course means that one big barrier to including the ar6k driver
is already removed.  You can browse the ar6k openmoko code at:

http://svn.openmoko.org/developers/sameo/patches/ar6k-ng/

Dan

Re: Getting Started

[Nick Kossifidis]

2008/2/7, Dan Williams <dcbw@redhat.com>:
> On Thu, 2008-02-07 at 11:09 -0500, Dan Williams wrote:
> > On Thu, 2008-02-07 at 17:04 +0200, Nick Kossifidis wrote:
> > > > For example, the openmoko people are writing a mac80211 driver
> > > > for ar6k. Not every driver is already in the wireless-2.6 git
> > > > tree.
> > >
> > > [OT]
> > >
> > > As far as i know Atheros released a GPLed driver along with their SDIO stack.
> > > http://sourceforge.net/projects/sdio-linux/
> > >
> > > Do you have a plan to include this in kernel ? What's the status ?
> >
> > 2.6.24 already has an SDIO stack; hence the Atheros one is redundant.
> > The openmoko people already have a port of their ar6k driver to the
> > in-kernel SDIO stack.
>
> Which of course means that one big barrier to including the ar6k driver
> is already removed.  You can browse the ar6k openmoko code at:
>
> http://svn.openmoko.org/developers/sameo/patches/ar6k-ng/
>
> Dan
>
>

Great news !

Thnx for the info ;-)

-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Getting started

[Dino Linux]

Hi

I hope I'm posting this in the right place, if not please let me know.

I've decided to help develop the Linux SPARC port. I wrote a few
printk_* patches once, and that's all the expirience I have in kernel
hacking. So I was wondering if you could recommend a few places to
learn about the Linux kernel and Linux on SPARC. I've seen a tutorial
somewhere called Linux Device Drivers, but it was a long time ago. I
was also wondering if there is a Linux/SPARC specific TODO list
somewhere so I can get started with the hacking :). I looked around on
ultralinux.org, but I didn't find one there.

     -dinolinux

getting started

[david linux]

I would like to help with the development of network
drivers for the 2.6 kernel.

Can you help me get a lead on who to contact for this?


Thanks,
-d


		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

Getting Started...

[Patrick Altman]

I know this is a common FAQ type question, but I haven't really seen one 
thus far in my web/usenet reading.

I am an experienced developer, mostly middle-layer/back-end web based 
applications.  I would like to start getting involved in the lower level 
programming in the Linux OS, and hopefully be able to be a contributor 
to the OS, even at some basic level, in the role of a developer.  I am 
not the "evangelist" type, just interested in the technology and in 
building technology.

Does anyone have any good suggestions as to a good book, web addresses, 
etc. that could help get me started?  I have been reading this mail 
group for about 3 weeks now and I must admit I am a little overwhelmed 
by all the different projects and issues that are "on-going".

Thanks!
Patrick Altman
patrick@pataltman.com
http://www.pataltman.com

Re: Getting Started...

[Vincent Hanquez]

On Tue, Jun 18, 2002 at 12:30:05AM -0700, Patrick Altman wrote:
> I know this is a common FAQ type question, but I haven't really seen one 
> [snip]
> by all the different projects and issues that are "on-going".

It may help you to find something to do:

http://www.kerneljanitor.org/
http://www.kernelnewbies.org/

(and #kernelnewbies, #kerneljanitor on openprojects's IRC.)

-- 
Tab

Getting started

[Jordan, Shane]

Ok I have a older Indy box here and I was wondering what I need to do to get
this thing running Linux.  From what I understand you have to have Irix
already installed on it.  Unfortunently we just threw a new harddrive in
with nothing on it and we don't have a copy of Irix.  Is there anyway to
install Linux on this badboy from scratch?  I'm willing to help our with
making binary package's ect if I can just get this thing booting into linux!
Any ideas, cd's ect?
Shane Jordan

Re: Getting started

[Keith M Wesolowski]

On Tue, Sep 26, 2000 at 10:20:14AM -0500, Jordan, Shane wrote:

> Ok I have a older Indy box here and I was wondering what I need to do to get
> this thing running Linux.  From what I understand you have to have Irix
> already installed on it.  Unfortunently we just threw a new harddrive in
> with nothing on it and we don't have a copy of Irix.  Is there anyway to
> install Linux on this badboy from scratch?  I'm willing to help our with
> making binary package's ect if I can just get this thing booting into linux!
> Any ideas, cd's ect?

Afaik there are still no CDs you can use. However, it is not true that
you need Irix. The current problem is lack of a bootloader. So most
people just boot over the network and then use local disk. Another
option, the one that requires Irix, calls for placing a Linux kernel
in an Irix efs filesystem. A third option, not terribly easy to do
without Irix, calls for placing an entire Linux kernel in the boot
block. I recommend netbooting for now, especially if you don't have
Irix.

There are several distributions of varying non-production quality
available. Start with the HOWTO at
http://oss.sgi.com/mips/mips-howto.html. For some reason, my distro
isn't included in that document even though I wrote a piece for it
(Ralf?), so see also http://foobazco.org/~wesolows/Install-HOWTO.html
- note that 0.2b is out but already getting fairly old. I know for a
fact that you can install it without Irix because that's what I did
from day one.

-- 
Keith M Wesolowski			wesolows@chem.unr.edu
University of Nevada			http://www.chem.unr.edu
Chemistry Department Systems and Network Administrator

Re: Getting started

[Erik Aderstedt]

Keith M Wesolowski wesolows@chem.unr.edu wrote:
> There are several distributions of varying non-production quality
> available. Start with the HOWTO at
> http://oss.sgi.com/mips/mips-howto.html. For some reason, my distro
> isn't included in that document even though I wrote a piece for it
> (Ralf?), so see also http://foobazco.org/~wesolows/Install-HOWTO.html
> - note that 0.2b is out but already getting fairly old. I know for a
> fact that you can install it without Irix because that's what I did
> from day one.
>

I'd really like to try out your distribution (I want to use a diskless Indy
as an X terminal) but the latest version I can find at your FTP site is 0.2a
and there are messages all over the place saying "0.2a is broken, don't use
it!". What gives?

Erik
------
Erik Aderstedt erik@ic.chalmers.se
Chalmers University of Technology
Solid State Electronics Laboratory

Re: Getting started

[Erik Aderstedt]

Keith M Wesolowski wesolows@chem.unr.edu wrote:
> There are several distributions of varying non-production quality
> available. Start with the HOWTO at
> http://oss.sgi.com/mips/mips-howto.html. For some reason, my distro
> isn't included in that document even though I wrote a piece for it
> (Ralf?), so see also http://foobazco.org/~wesolows/Install-HOWTO.html
> - note that 0.2b is out but already getting fairly old. I know for a
> fact that you can install it without Irix because that's what I did
> from day one.
>

I'd really like to try out your distribution (I want to use a diskless Indy
as an X terminal) but the latest version I can find at your FTP site is 0.2a
and there are messages all over the place saying "0.2a is broken, don't use
it!". What gives?

Erik
------
Erik Aderstedt erik@ic.chalmers.se
Chalmers University of Technology
Solid State Electronics Laboratory

Re: Getting started

[Keith M Wesolowski]

On Wed, Sep 27, 2000 at 07:05:09AM +0200, Erik Aderstedt wrote:

> I'd really like to try out your distribution (I want to use a diskless Indy
> as an X terminal) but the latest version I can find at your FTP site is 0.2a
> and there are messages all over the place saying "0.2a is broken, don't use
> it!". What gives?

Hmmm, poor documentation. All the more recent stuff is now at
ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple/.

-- 
Keith M Wesolowski			wesolows@chem.unr.edu
University of Nevada			http://www.chem.unr.edu
Chemistry Department Systems and Network Administrator