June 20th, 2019Linux+USB

Introduction

Recently I needed to write some drivers for the specific USB-scanner. This scanner is working in mode of uninterruptible scan-out with the frequency of 10 shots per second and provides the speed of stream for reading of 3.2Mb\sec.

First the drivers were developed for Linux core version 2.6.15, but later, under the client’s demand, they were adapted for the core version 2.4.26. Surprisingly, it wasn’t hard at all to write drivers fro both core versions. For this purpose you need just to know clearly how USB works and which functions provide interoperation of the driver and USB-device. All the other things are instantiated in core of linux.

The following tasks I see before writing down the following article:

1. telling about basic properties of devices change by USB
2. describing programming interface of the interoperation between driver and USB-device
3. give examples of core functions usage

Hope, the following information is interesting for the system level programmers.

Introduction to USB

Probably, there is no sense to speak about such obvious things, as wide
spread of USB, high speed of an exchange on USB, an opportunity of
hot connection of devices. Already each PC user anyhow has valued the advantages and pluses of USB.

Therefore we shall pass to less obvious things at once: how is USB
arranged inside.

Who is the boss?

One of main concepts of USB is that
there can be only one master in USB-system. It is host-computer. USB-
devices always answer inquiries of a host-computer – they can never
send the information independently.

There is only one exception: after the host has transferred the device in
the suspend-mode, the device can send inquiry remote wakeup. In all
other cases the host forms inquiries, and devices answer on
them.

Direction

Host is always the master, and data exchange should be carried out in
both directions:

* OUT – sending packet with flag OUT, host is sending data to device

* IN - sending packet with flag IN, host is sending enquiry for receipt of data from device.

You just need to adjust to it. Host is sending packet with flag IN just for receiving the data from device. smile

Packets classification in USB

Few packet types could by transferred through USB:
1. Token - enquiry, contains driving information: direction of the operation(IN, OUT), number of the endpoint
2. Data – data packet
3. Handshake – utility packets, may contain confirmation (ACK),
error message, abruption (NACK)
4. Special – service packets, such as PING

More detailed information about packets, mentioned in USB specification, you may read in [2,3]. Let’s view few examples of these packets usage.

Example: sending data to device

Host sends packet Token “OUT”, then packet Data in order to send data to device. If device is ready to process received data, it sends packet Handshake “ACK”, which confirms transaction. If it is busy, it sends refusal – Handshake “NACK”. If any mistake took place, device may not send Handshake.

Example: sending data to host

As told before, device never sends data itself. Only on-request. In order to except data, host sends packet Handshake “IN”. Device may send packet Data on-request, then Handshake “ACK”. Or it may send Handshake “NACK” without sending Data.

Types of data transfer

USB specification defines 4 types of data streams:
1. bulk transfer - assigned for packet data transfer with the packet sizes of 8, 16, 32, 32 for USB 1.1 and 512 for USB 2.0. Algorithm of resending is used (in case of mistakes appearing), and the stream driving is conducted with handshake packets usage. That’s why this type is legal. Both directions IN and OUT are supported.

2. control transfer – assigned for configuring and driving the device. As well as bulk, algorithms of confirmation and resending, that’s why this type provides with guaranteed data exchange. Directions – IN (status) and OUT (setup, control).
3. interrupt transfer - similar to bulk. Packet size - from 1 to 64
byte for USB 1.1 and up to 1024 byte for USB 2.0. This type guarantees, that device is inquired by host in specified interval (this means that host will send it token “IN”). Direction – IN.

4. isochronous transfer - assigned for data transfer without stream driving (without confirmation). Field of application -
audio-streams, video-streams. Packet size – up to 1023 byte for USB
1.1 and up to 1024 byte for USB 2.0. Mistake control is provided (for the excepting side) on CRC16. Directions - IN and OUT.

Endpoint - source/receiver of the data

USB specification defines endpoint (EP), as data source of data receiver. Device may have up to 32 EP: 16 for input and 16 for output.
Access to this or that endpoint happens according to its address.

For example,let us suppose, that host is intended to read data packet from EP4 (fourth endpoint of the device) with the help of “bulk transfer” type. It sends packet token “IN”, where it indicates the address of the endpoint. Corresponding source in the device sends data packet to host. Data packet transfer happens the same way.

Endpoint No.0

EP0 has a special value for USB. It is Control EP. It has to be in each USB-device. This EP uses token “setup”, in order to signalize that sending data coming after it are intended to drive the device. In most cases setup-packet transfer is enough. Nevertheless, device may use data transfer through EP0 as well, e.g. for components’ insertions change, or for receiving of expanded information about the device.

Let’s view setup-packet in details.

EP0: setup-packet

Contents of setup-packet is represented in the following table

Byte (No.) Name Mapping
0 bmRequestType Field for indicating request type, direction, receiver
1 bRequest Request identifier
2 wValueL 16-byte value wValue, depends on request.
3 wValueH 16-byte value wValue, depends on request.
4 wIndexL 16-byte value wIndex, depends on request.
5 wIndexH 16-byte value wIndex, depends on request.
6 wLengthL byte quantity, sent after setup-packet.
7 wLengthH byte quantity, sent after setup-packet.

As you may see in the table above, setup-packet contains 5 fields. bmRequestType and
bRequest specify request, and wValue, wIndex and wLength – its values.

USB specification preserves value range bRequest according to standard requires. Each device is obliged to reply all the standard requires. There are few standard requires in the following table.

bRequest Name Description
0×05 Set Address Installation of the unique address of device in the system

0×06 Get Descriptor Receipt of information about device. Type of information depends on field wValue.

Other range device may use as it thinks fit. Detailed data is available in [2,3].

Detection of the device

How is device detected when it is freshly connected to system? It was mentioned already, that each device has to provide access to REP0. But besides it has to reply the enquiries indicated in USB specification for EP0. Detection of the device in system happens due to these enquires.

Algorithm of new device detection is as follows:
1. host sends setup-packet “Get Descriptor” (wValue = “device”).
2. host receives identifying information about device
3. host sends setup-packet “Set address”, then device receives unique address in system
4. host sends other setup-packets “Get Descriptor” and receives additional information about device: quantity of EP, power requirements, etc.

USB support in Linux core

Programming interface for interaction with USB devices in Linux core is very simple. Under the simple interface all the algorithms of enquiries sending, confirmation tracking, mistake control, etc. are hidden. All the details, described in previous part are instantiated in Linux core.
In the core all the program files are located in drivers/usb/, and heading files are located in include/linux/. Information represented in this directories is enough to write driver for any USB-device individually.

Driver, interacting to USB-device usually takes the following actions:

1. registration\unloading of the driver
2. registration\removal of the device
3. data exchange: driving and informational.

Let’s examine them in details relating to embedding under the core 2.6.15. For better neatness we need to understand basic principles of UDM [4, 5] which appeared in core 2.6.

Registration\uploading of the driver.

Registration of the USB driver means:
1. filling the structure usb_driver
2. registration of the structure in the system

The structure usb_driver is described in include/linux/usb.h Let’s examine the most important fields of this structure.

struct usb_driver {
// …
const char *name;
int (*probe) (struct usb_interface *intf,
const struct usb_device_id *id);
void (*disconnect) (struct usb_interface *intf);
const struct usb_device_id *id_table;
struct device_driver driver;
// …
};

Evidently, name is the name of driver. id_table is the array of structures
usb_device_id. This list is assigned for definition of connected devices’ conformance to certain parameters. Only those devices, which conform to the listed parameters may be connected to driver. If the array is empty, system tries to connect each device to the driver.
Field driver indicates, that usb_driver is derived from device_driver.
In the most simple case each element of id_table[i] contains few identifiers:

* identifier of manufacturer (Vendor ID)
* identifier of the device (Device ID).

Definition of the structure usb_device_id may be seen in
include/linux/mod_devicetable.h

probe and disconnect; these are callback-functions, fetched by system while connecting and disconnecting of the USB-device. probe will be fetched for each device, if the list id_table is empty, or only for those, which correspond to the listed parameters.

Example.

#include

#define MY_DEV_NAME “my_usb_device”
#define PRODUCT_ID 0×1
#define VENDOR_ID 0×1234

static struct usb_device_id my_table [] = {
{ USB_DEVICE(VENDOR_ID, PRODUCT_ID) },
{ } // terming list element
};

static struct usb_driver my_driver = {
.name = MY_DEV_NAME,
.probe = my_probe,
.disconnect = my_disconnect,
.id_table = my_table,
};

static int __init my_module_init(void)
{
// registering driver
return usb_register(&my_driver);
}

static void __exit my_module_exit(void)
{
// unloading driver
usb_deregister(&my_driver);
}

In this example the driver of USB-device, which has fields’ meanings
PRODUCT_ID = 0×1, VENDOR_ID = 0×1234 is registered. Function my_probe will be fetched only for device with such parameters.

Fetching my_probe in fact means registration of the device in driver
my_driver, and fetching my_disconnect means removal of device. So let’s pass on the next stage – registration\removal of the device.

Registration of the device.

One registered driver is able to “connect” few devices. For connecting device to the driver system fetches driver’s function probe, which transfers 2 parameters:

static int my_probe(struct usb_interface *interface,
const struct usb_device_id *id)
{
// …
}

interface is the interface of the USB-device. Usually USB-driver
interacts directly not with the device, but with its interface. id -
contains information about the device. If the function retrieves 0, this means that device is registered successfully, otherwise system tries to “attach” device to any other driver.
To disconnect device from the driver system fetches function
disconnect, to which the only parameter is send – interface:

static void my_disconnect(struct usb_interface *interface)
{
// …
}

In generic case, the structure in memory for each connecting device is allocated in function probe, it is filled and then registered, e.g. symbolic device, and the registration of the device in sysfs is carried out. Also verification for the necessary EP could be carried out in function probe.

As an example of registration\removal of the device you’d better apply to example from the linux core, which is located in drivers/usb/usb-skeleton.c.

Usage of USB Major

Let’s examine the registration of symbolic device in details. As it is already known, for the registration of symbolic device we need to receive number major, whether statically (apply to maintainer of the core and insert it into include/linux/major.h), or dinamically (fetching
register_chrdev with parameter major = 0). When symbolic device is registered, it is necessary to create file in directory /dev. For this purpose we may use whether command mknod (from user-space) or
functions devfs, if this core supports devfs.

In the core version 2.6 the operation described above is much simplified due to appearing of udev and sysfs. Program-daemon udevd is working in the system, which tracks appearance of files in sysfs (/sys/class/). On the basis of information read from these files, it creates necessary files automatically in dev, using the rules udev for the current device.
For these purposes there is function usb_register_dev in programming interface of USB. It processes all the necessary for udev to conduct the listed above operations:

extern int usb_register_dev(struct usb_interface *intf,
struct usb_class_driver *class_driver);
extern void usb_deregister_dev(struct usb_interface *intf,
struct usb_class_driver *class_driver);

usb_register_dev excepts for input interface è class_driver. Structure
usb_class_driver looks as follows:

struct usb_class_driver {
char *name;
struct file_operations *fops;
int minor_base;
};

name - is the name of the device. Direcory with this name will appear in sysfs.
fops - file operations of the symbolic device. minor_base - basic
minor number.

Function usb_register_dev carries out the following actions:

* registeres symbolic device with major number 180 (include/linux/major.h) and backups the range from 16 minor numbers
That’s why minor_base needs to have junior half-byte = 0.

* points out one number for the current device from the backuped range of minor numbers. This number is written in â interface->minor.

* creates all the necessary files in sysfs: after this udev creates files in /dev/

Fetching of usb_deregister_dev carries out opposite options, that is why it has to be fetched in function disconnect.

Data exchange with the device

Let us examine data exchange for the most frequently used types:
control and bulk. Corresponding functions are defined in
drivers/usb/core/message.c.

Control transfer

For the sending\receiving of the data in zero EP function
usb_control_msg is used:

extern int usb_control_msg(struct usb_device *dev, unsigned int pipe,
__u8 request, __u8 requesttype, __u16 value, __u16 index,
void *data, __u16 size, int timeout);

dev - reference to usb_device. This indicator can be received by fetching of the function interface_to_usbdev(interface). pipe - EP pipe.
This parameters contains: type of data transfer(bulk, control, …),
direction, number EP. For specifying pipe in include/linux/usb.h
macros are defined. Below are few of them:

#define usb_sndctrlpipe(dev,endpoint) \
((PIPE_CONTROL << 30) | __create_pipe(dev,endpoint))
#define usb_rcvctrlpipe(dev,endpoint) \
((PIPE_CONTROL << 30) | __create_pipe(dev,endpoint) | USB_DIR_IN)

#define usb_sndbulkpipe(dev,endpoint) \
((PIPE_BULK << 30) | __create_pipe(dev,endpoint))
#define usb_rcvbulkpipe(dev,endpoint) \
((PIPE_BULK << 30) | __create_pipe(dev,endpoint) | USB_DIR_IN)

Parameters request, request_type, value, index are the fields setup-packet.
Their contents depends on application. data, size are the array for sending\receiving. Look above [2,3].

timeout is parameter, specifying how much time is given for sending\receiving.

It is necessary to keep in mind that function usb_control_msg retrieves the value only after setup-packet and data are delivered or if a mistake of time-out take place. This function uses fetching interruptible_sleep_on, that is why this function shouldn’t be used in breakup.

Example. Sending of setup-packet with specified bRequest and wValue can look ad follows:

// …
int ret;
struct usb_device* udev = interface_to_usbdev(interface);

ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
bRequest, USB_TYPE_VENDOR,
wValue, 0, udev, 0, HZ);
// …

In this example only setup-package is sent. That is why data = udev,
size = 0.

Bulk transfer

For usage of bulk transfer function usb_bulk_msg is used:

extern int usb_bulk_msg(struct usb_device *dev, unsigned int pipe,
void *data, int size, int *actual_size,
int timeout);

Attributes dev, pipe, data, size, timeout have the same meaning as in
usb_control_msg. actual_size - quantity of actually transferred data. actual_size <= size.

usb_bulk_msg has the same attribute with usb_control_msg – it cannot be fetched if breakup.

Example. Accepting of 100 byte from 5th EP can look as follows:

// …
struct usb_device* udev = interface_to_usbdev(interface);
u8 buf[[ ;]]
int ret, actual_size;
ret = usb_bulk_msg(udev, usb_rcvbulkpipe(udev, 5), buf, 100, &actual_size, HZ)
;
// …

Conclusion

USB specification defines large quantity of data transfer types, packets, algorithms. All the USB algorithms are instantiated in linux core. Convenient and simple interface is represented to drivers programmer in terms of set of functions, macros, structures. In linux core 2.6 subsystem of USB is fit well into the model UDM[3,4], this makes it flexible for interaction with udev, sysfs.

May 21st, 2019Linux Users

Source: http://www.ahinc.com/linux101/users.htm

Every user who has access to a Linux system needs a login and a password. Each user must belong to a primary group and for security or access purposes can belong to several secondary groups.

In order to create new logins, modify or delete users, you must already be logged in as root.
The root login is the highest level and only certain individuals should have access to the root account.

useradd - Adding a new user

Options:

  • -d home directory
  • -s starting program (shell)
  • -p password
  • -g (primary group assigned to the users)
  • -G (Other groups the user belongs to)
  • -m (Create the user’s home directory

Example:
To add a new user with

  • a primary group of users
  • a second group mgmt
  • starting shell /bin/bash
  • password of xxxx
  • home directory of roger
  • create home directory
  • a login name of roger

useradd -gusers -Gmgmt -s/bin/shell -pxxxx -d/home/roger -m roger

top of page


usermod - Modifying existing user

Options:

  • -d home directory
  • -s starting program (shell)
  • -p password
  • -g (primary group assigned to the users)
  • -G (Other groups the user belongs to)

Example:
To add the group ‘others’ to the user roger

usermod -Gothers roger

top of page


userdel- Deleting a user

Options:

  • -r (remove home directory)

Example: To remove the user ‘roger’ and his home directory

userdel -r roger

top of page


passwd - User’s Password

Options:

  • user’s name (Only required if you are root and want to change another user’s password)

Example:
To change the password for the account you are currently logged in as…

passwd
Enter existing password
Enter new password
Enter new password again (to validate)

Example:
To change the password for the user ‘roger’ (only you are logged in as root)…

passwd roger
Enter existing password
(can be either roger’s password or root’s password)
Enter new password
Enter new password again
(to validate)

top of page


Where user and group information stored

User names and primary groups are stored in /etc/passwd. This file can be directly edited using the ‘vi’ editor, although this is not recommended. Format of the file is…

  • User name (normally all lower case)
  • Password (encrypted - only contains the letter ‘x’)
  • User ID (a unique number of each user)
  • Primary Group ID
  • Comment (Normally the person’s full name)
  • Home directory (normally /home/<user name>
  • Default shell (normally /bin/bash)

Each field is separated by a colon.

Passwords for each user are stored in /etc/shadow. This file should only be changed using the passwd command.

Group information is stored in /etc/group. This file can be directly edited using the ‘vi’ editor. Format of the file is…

  • Group name
  • Group password (hardly ever used)
  • Group ID
  • User names (separated by commas)

Each field is separated by a colon.

Default files

When a new user is created, the default files and directories that are created are stored in /etc/skel.

This directory can be modified to fit your needs. Modifications only effect new users and does not change anything for existing users.

top of page


su
- Switch User

To switch to another user, use the su command. This is most commonly used to switch to the root account.

Example:
To switch to root account…

su
Enter root’s passwd

Example:
To switch to the user ‘roger’…

su roger
Enter roger’s or root’s passwd

To return
to original user, enter exit

top
of page

http://news.softpedia.com/

Tim Burke, the director of emerging technologies with Red Hat talked at the Linux/Open Source on Wall Street conference that took place on April 23, about Red Hat initiative of developing the Linux kernel by changing almost 1.2 million lines of code and working on the patches which ensure a proper observing of the processes hierarchy for a better stability.

He also mentioned that the Red Hat community runs severe tests over the code before adding it to the kernel so that it is highly improbable to generate any fatal errors. Many projects driving real-time requirements involve messaging, and the target of these real-time capabilities is to foresee in response time and to ensure that the highest priority processes run first.

“The key challenge of getting this done is to remove ‘black holes’ in the Linux kernel […] There can also be downsides to real time, one of which is that average throughput might decrease. Real-time capabilities do not solve all the world’s problems. But, on the positive side, recompilation is not required” - Burke said.

John O’Hara, chairman of the AMQP (Advanced Message Queuing Protocol) working group, shared his view over the AMQP open standard for middleware benefits. AMQP has been in development for more than three years before going public on June 20, 2006. According to O’Hara, the AMQP protocol layering is network friendly, the infrastructure data is binary, it is independent of JMS (Java Message Service) and multivendor interoperable.

By: Lisa Hoover

Linux on Wall Street routinely draws 800 to 1,000 attendees each year and organizer Russell Flagg says that is a testimony to just how much value the Wall Street community sees in using open source alternatives to expensive and often limiting proprietary business solutions.

“We don’t just focus on Linux exclusively, though,” says Flagg. “We’ve expanded over the years to include open source on the whole. Wall Street has already made huge investements in other operating systems and legacy systems and [this conference] helps find alternative solutions that that are less expensive, more robust, and more agile. There is a continued search on the part of Wall Street to find other systems as capable as what they already have.”

Flagg says the idea for the event took shape after he and fellow organizer Pete Harris spoke to representatives from IBM, Red Hat, Intel and other companies that understand how open source products can impact the business world. “We found an untapped niche in the financial market” and the conference was born.

Presenters and speakers were carefully selected to help attendees sort through mountains of information and take useful information back to their companies. “We have a very free-form conference,” says Flagg. “We let speakers decide for themselves what they think is appropriate information rather than go through PR channels” to shape the presentations and offer actionable information.

“Seventy percent of our conference-goers are the ’suits’ — decision makers and business people. The other thirty percent are developers focused on technology. So, primarily, our speakers are the Wall Street guys who are being collegiate and sharing information with their colleagues on Wall Street. After all, Wall Street listens to Wall Street.”

Conference planners haven’t forgotten about who makes open source deployments work behind the scenes, though, and invite IT managers to attend the event as well. “IT managers are given mandates to lower costs and reduce budgets so open source is a great option. It’s a tough world out there for them — they must do more with less and still maintain capabilities in a 24/7 world. It’s a balancing act.”

Panels and speakers

Raven Zachary, Open Source Research Director for The 451 Group, will share his views on Wall Street’s adoption of open source during a panel titled “Selling Open Source To The CIO.” Zachary and fellow panel members from Oracle, Intel, and Jefferies & Company will participate in a moderated discussion of how the CIOs in the financial market perceive Linux and how to overcome their objections, something Zachary says is important for vendors in the space to remain competitive.

“The Financial Services firms are leading the enterprise adoption of open source technology, including Linux,” says Zachary. “By watching the consumption patterns of these firms, open source vendors can gain a good understanding of the types of products and services that are commercially viable.

“We’re seeing an increased effort by Financial Services services to recruit open source project developers. Bringing expertise in-house is a growing trend. The challenge is that the demand for open source talent is growing at a greater rate than the expansion of this talent pool. Developers contributing to popular open source projects are in high demand and are in a great position to obtain employment.”

Zachary says that despite the fact that Wall Street has already invested millions in proprietary hardware and software, they can easily see the value in exploring other alternatives. “Open source adoption with Financial Services is not just about cost. Standards are a big part of this value. Standards provide greater longevity, ease of future migration, and talent acquisition, to name just a few.”

Using free and open source software is not without risks however. Phil Robb, Engineering Section Manager in the Open Source and Linux Organization (OSLO) at Hewlett-Packard will give a presentation titled, “Open Source Governance: Recognizing and Dealing with the Unique Risks Associated with Free Software.” Robb will discuss best practices to help companies protect themselves from the possibility of legal and technical pitfalls associated with using open source products.

Doug Small, Director of Marketing for OSLO, says that despite the potential drawbacks of adopting open source, the financial market has demonstrated they are more than ready to incorporate it into their business models.

“Financial services companies have been early adopters of Linux. First we saw Wall Street firms begin using Linux, then banks and mutual funds. [Now] we see insurance companies beginning to Linux more broadly and we are seeing Linux used in progressively more critical deployments.

“We see a growing role for open source software beyond Linux in financial services companies and that’s why many companies are expanding the governance policies and procedures around using open source software.”

Event organizer Russell Flagg says a lot of ground will be covered during the day-long conference but he believes that, as in past years, attendees will come away with a better understanding of how Linux and open source fits into the Wall Street world. “We don’t often hear about the real-world implementations that happen as a result of this conference,” he says, “but the success of the conference each year I think is an indication that [open source] applications are definitely being considered.”

Source: Linux Community

Saved from www.itmanagersjournal.com

Author: Bruce Byfield

The GNU General Public License (GPL) is one of the most widely used software licenses — and, undoubtedly, the most misunderstood. Some of this misunderstanding comes from hostile propaganda, but some also comes from a lack of experience in licensing issues on the part of both lawyers and lay users, and the use of standard language in conventional end-user license agreements that are unthinkingly coupled with the GPL. In all cases, the confusion is frequently based on misreadings, rumors, secondhand accounts, and what is convenient to believe.

To get a sense of the most common misunderstandings, NewsForge consulted with three experts: Richard Fontana, a lawyer with the Software Freedom Law Center and one of the main drafters of the third version of the license; David Turner, former compliance engineer at the Free Software Foundation who is assisting with the revisions of the license; and Harald Welte of the GPL-Violations project, which tracks possible cases of non-compliance and tries to assist in resolving them. Taken together, the opinions of these experts offers a summary of the most common misunderstandings about the GPL, from comic exaggerations to potentially legitimate differences of opinion.


1. The GPL is viral

The idea that any software that comes into contact with GPL-licensed software also becomes subject to the GPL seems to have originated with Craig Mundie, a senior vice president of Microsoft, in a speech delivered at the New York University Stern School of Business in May 2001. Since then, David Turner reports, many people have come to believe that even having GPL software on the same computer brings other software under the license. In extreme cases, Turner says, this belief has lead to bans on all GPL software at some companies.

This misunderstanding stems from section 2 of the current GPL, which states only that modified versions of GPL software must also be licensed under the GPL. However, the section clearly states that if a program “can be reasonably considered independent and separate works in themselves, then the GPL does not apply to it” and that being on the same “storage or distribution medium does not bring the other work under the scope of this License.” As Fontana points out, the definition of a derivative work could be clearer — and should be in the third version of the license — but the general principle is unmistakable.


2. The GPL is unenforceable

At the opposite extreme from the idea that the GPL is viral is that it is unenforceable — or, in Turner’s words, “It’s just a bunch of hippies. How are they going to force us to do anything?” Turner attributes this misconception at least partly to the Free Software Foundation’s preference for helping violators come into compliance rather than resorting automatically to lawyers and the courts. Yet this preference can also be reversed; the fact that violators consistently prefer compliance to a legal battle strongly suggests that they believe the license would be enforced. More importantly, in the few cases where the GPL has gone to court, such as Welte v. Sitecom in Germany or Drew Technologies, Inc. v. Society of Automotive Engineers, Inc. in the United States, the license has been indirectly or directly upheld.


3. You can’t charge for GPL software

Some of the first words in the GPL are, “When we speak of free software, we are referring to freedom, not price.” Yet despite repeated reminders from the Free Software Foundation, including one on its home page, even some members of the free software communities believe that charging money for GPL software is illegal. Dozens of companies, including Red Hat and Novell, who continue to charge for free software, daily prove otherwise.

The only mentions of price in the GPL come in section 1, which states that, “You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee,” and section 3b, which states that source code must be provided “for a charge no more than your cost of physically performing source distribution.”


4. The “liberty or death” clause applies absolutely

Section 7 of the GPL is sometimes tagged as the “liberty of death” clause because it states that conditions imposed by court orders or allegations of patent infringement do not release users of the license from following its conditions. Instead, if they cannot meet both the imposed conditions and the GPL’s conditions, they must stop distributing.

According to Fontana, many users interpret section 7 far too rigorously. Although the section applies only to patent licenses that prohibit users from passing on full GPL rights, Fontana says, “Some read the section as prohibiting distribution of GPLed code under the benefit of any non-sublicensable patent license.” In addition, “some have worried about the existence of a possibly-applicable patent, or of some law or regulation that might potentially be applied to everyone in a particular jurisdiction is enough to trigger this jurisdiction.” Neither reading is supported by the actual text of the license.


5. Distributors only need to ship the source code they alter

Section 5 of the GPL states that “by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions.” These conditions include the obligation to provide the source code of the works distributed. However, many maintainers of software derived from other works conveniently believe that, so long as the distributors of the original work are distributing source code, they only need to provide the source code for the works that they modify. As mentioned in a recent NewsForge article, this assumption seems especially widespread among maintainers of derivative GNU/Linux distributions. Unfortunately, while the need for all distributors to provide source code sometimes seems redundant and often onerous, the GPL does not allow any provisions for exceptions. Nor is it likely to in the future, according to Turner.


6. Distributors only need to supply source code, and not the means to use it

Under section 3 of the GPL, providing the source code is only part of a distributor’s obligation. The section defines the complete source code as not only “the source code for all modules” and “any associated interface definition files,” but also “the scripts used to control compilation and installation of the executable” — in other words, the tools needed to make the source code useful to anyone. Within the free software community, many people will already have those tools, but distributors cannot assume that all recipients will.


7. Distributors don’t need to provide offers of source code

The GPL in section 3 permits users to either distribute source code with binary files, or to include an offer to provide the source code. To do neither and wait for requests may be less work, but is a straightforward violation.


8. Distributors only need to offer source code to their customers

If distributors opt to provide an offer for source code, then under section 3b, the offer must be good for three years, and must apply to “any third party.” No distinction is made between commercial customers and anyone else who might be interested in the source code.


9. Distributors only need to link to the license text

Providing only a link to the GPL is easy for the distributor, but a clear violation of section 1, which grants the right to distribute GPL software “provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice.” Welte explains that this provision is necessary because all users may not always have Internet access to read the license. If they cannot read the license, they cannot understand the terms under which they are allowed to distribute the software.


10. I don’t think that word means what you think it means

Richard Fontana points out that a handful of confusions about the GPL are not misunderstandings, but potentially valid differences based on differences of opinion or interpretation under law. “Perhaps the most fundamental difference,” he says, “has to do with what a ‘work’ of software is, in the copyright law sense. The GPL assumes that the underlying legal system will provide a reasonable answer to this question. The work includes what a programmer would objectively regard as being part of the same program.” However, others with different philosophies or approaches to the issue might define different works in other terms, such as the files that they use.

Similarly, while the current version of the GPL refers to “distribution” of a work, Fontana notes that the word can have different legal meanings. For example, he says, “The meaning may vary in the United States depending on whether one is talking about distribution in the copyright law sense or distribution in the sense of ordinary commercial usage.” Moreover, in other countries, “distribution” or its equivalent may not occur in copyright law, or be used in a different sense.

One of the main goals of the latest draft of the new version of the GPL is to reduce these ambiguities by starting the license with definitions and changing terminology. “Distribution,” for instance, has been replaced with “propagate” and “convey.” But, until the third version is finalized in early /2007/, the problems of definition will remain.


Future misunderstandings

Many misunderstandings about the GPL may be eliminated or reduced by the next version of the license, which, so far, has included many attempts to clarify its intentions. In fact, Turner believes that the extensive consultation that is part of the revision process may educate users in itself. “Here,” he says, “is their chance to discuss the license publicly. They can read the discussion and see how the Free Software Foundation came to its decisions. It gives people an information pool.”

At the same time, the upcoming changes may create their own set of misunderstandings. After all, one of the reasons for the revision is to take into account new considerations, such as BitTorrent distributions, that did not exist when the current text was written. In addition, while changes in terminology may make the license easier to apply in different jurisdictions, those familiar with the old terms may be confused. Turner wonders whether the old terms will “stick around, if only subliminally, and will confuse people.”

In the end, Turner concedes, some degree of confusion is probably inescapable. “There’s always going to be people who misunderstand,” he says, “no matter how you write the license, even in words of one syllable.”


Bruce Byfield is a course designer and instructor, and a computer journalist who writes regularly for NewsForge, Linux.com and IT Manager’s Journal.

So you’ve been using Linux for a while now and have decided to take the next step. Whether you are looking for a performance increase, added hardware support or even just to enhance your geek cred, compiling your own kernel need not be a horrifying experience. Compiling a kernel has historically been a very involved and, at times, frustratingly hair pulling experience for new Linux users. All that has changed however with new tools making it easier than ever before to roll your own. In this article I will take you through the whole process, step by step, from downloading to booting your new kernel.

Obtaining your new Kernel

Many distributions either install the source for the current kernel or make it available via the package manager, some distributions even make it possible to install a new kernel via the package manager. The downside to this is that it isn’t going to be the latest kernel and that you aren’t going to get the same level of customization as you do when compiling your own. Therefore we need to go straight to the source (excuse the pun) and download our kernel from www.kernel.org. I would recommend downloading the ‘Latest Stable Version’ by clicking on the ‘F’ link beside the release date. This will take some time to download on slower connections, feel free to continue on to the ‘Preparing Your System’ section while you wait for your new kernel to download.

Preparing Your System

The main prerequisite to compiling your own kernel is (not surprisingly) a compiler, if a compiler is not installed on your system then use your distributions package management tools (Apt, Yum, Synaptic, Emerge, etc…) to install the most recent version of gcc (the GNU compiler). You will also need to install the bzip2 package using your package manager. Debian users can install the build-essential package to ensure that they have all the tools required to build things. NCurses is also required for those using menuconfig, however we will be using xconfig in this article which is a bit friendlier and for that NCurses isn’t needed. You will also need to use mkinitramfs, which will be available with most package managers in the form of mkinitramfs-tools, or similar and is used to create a temporary file-system in Ram to boot the kernel from. If your package manager doesn’t provide these tools they can be downloaded from the following locations:

gcc - http://gcc.gnu.org/

bzip2 - http://www.bzip.org/

mkinitramfs - http://sourceforge.net/projects/mkinitramfs/

Unpacking Your Kernel

Once your kernel is downloaded you need to move it to your /usr/src/ directory and unpack it. You then need to create a link from your actual kernel source directory to the default kernel source location /usr/src/linux/. Follow the commands below, replacing linux-2.6.20-1 with the version you have downloaded and /home/fred/ with the location that you have downloaded the kernel to.

mv /home/fred/linux-2.6.20-1.tar.bz2 /usr/src/

tar -jxvf linux-2.6.20-1.tar.bz2

ln -s /usr/src/linux-2.6.20-1/ /usr/src/linux

Configuring Your Kernel

The configuration file for your kernel has over 2000 options, most of which mean absolutely nothing to most people, therefore we don’t want to have to set each one individually. The easy way around this is to copy the configuration file for your current kernel and modify that. The config file for your current kernel is in the /boot/ directory, If you were using a 2.6.17 kernel your config file would be /boot/config-2.6.17. When you are configuring a new kernel it creates a .config file in the /usr/src/linux/ directory, if one already exists it loads the settings from that and saves changes back to it. Therefore, you need to copy the config file from your /boot/ directory to /usr/src/linux/.config. To do so run the command below, replacing 2.6.17 with your current kernel version.

cp /boot/config-2.6.17 /usr/src/linux/.config

Now change to the /usr/src/linux/ directory and run the command make xconfig.

cd /usr/src/linux/

make xconfig

This will bring up the configuration menu with all the defaults from your current kernel already set. A tick in a box indicates that the driver will be compiled in to the kernel and loaded at every boot (each tick slows down your kernel a fraction), a dot in a box indicates that the driver will be compiled as a module which will only be loaded when you request it to and a blank box indicates that the driver will not be available at all. If you are compiling solely to enable a piece of hardware then skip to the ‘Device Drivers’ section, locate the appropriate sub-directory and enable the option for your device, then skip to the next section. If however you are here to trim excess fat and gain precious speed then read on. The list below contains a list of options, with short descriptions, which can commonly be removed without harming your system. If you have a piece of hardware which isn’t supported under your current kernel, it may be supported under the new kernel, just find the corresponding menu and enable it. I make no guarantees that removing one of these devices won’t render your new kernel unusable on your system, but if this does happen then you can always re-enable the option and recompile.

Processor Type

In the Processor Type and Features section under ‘Processor Family’ select the option that matches your CPU.

Bus Options

Disable ISA and MCA unless you have a very old PC (more than six years old) that you know has ISA or MCA slots.

Disable PCCard(PCMCIA/Cardbus) support unless you are using a laptop.

Disable PCI Hotplug Support as it is not available on common hardware.

Device Drivers

Disable all SCSI low-level drivers unless you have special SCSI hardware (mostly used for servers and Mac hardware.

Disable all Fusion MPT device support unless you know you have this SCSI card.

Disable ISDN support unless you are in a part of the world that still uses ISDN for Internet.

Disable Linux telephony support unless you have a special card to connect a regular phone to your PC for VOIP applications.

Enable Advanced Linux Sound Architecture if it is not already enabled. If you know what kind of Sound-card you have you can also disable any other drivers under the ‘Generic Devices’, ‘PCI Devices’ and ‘USB Devices’ sub-menus.

Disable Open Sound System

Disable Infiniband Support unless you know you have special infiniband hardware.

File Systems

Under ‘Miscellaneous Filesystems’, enable Compressed Rom File Support(cramfs) and disable all others unless you have a specific need to access a special file-system type.

Under ‘Partition Types’ disable all except PC BIOS (enable all sub-menus) and Windows Logical Disk Manager Support

Now that you have finished selecting your options click on the ‘Save’ icon (the floppy disk) and exit the utility.

Compiling Your Kernel and Modules

Once the configuration is saved, the next step is to compile the kernel. To compile the kernel itself run ‘make’ from within the /usr/src/linux/ directory. This will take a long time, on old systems it will take a very long time and your system will be unusable for other tasks while it compiles.

cd /usr/src/linux/

make

Next we build and install the modules.

make modules_install

Installing Your Kernel

Now that we have a fully customized and compiled kernel, we need to tell the system where it is and what to do with it. First we will install it in the appropriate place and create the necessary links to it. Then we will generate a ramdisk which the system will use at boot time to load the kernel. Then we will update your boot-loader to recognize the new kernel. If all goes according to plan we will then be able to boot the new kernel. As usual replace 2.6.20-1 with the actual version of your new kernel.

Install the kernel in /boot/ and create links.

cd /usr/src/linux/

make install

Generate a Ramdisk

cd /boot/

mkinitramfs -o initrd.img-2.6.20-1 2.6.20-1

Update Grub or Lilo (depending on which you have, usually Grub).

Grub:

update-grub

Lilo:

lilo

Conclusion

Hopefully you still have all your hair and you now have a brand spanking shiny new racey kernel. Reboot your PC and select your new kernel from the boot menu. If for some reason it doesn’t boot, your old kernel will still be available and you can try again. For those of you with an adventurous streak, now is the time to go back in to xconfig and try and refine your selections even further.

Saved From http://www.linuxforums.org/desktop/the_newbies_guide_to_compiling_your_first_kernel.html

Dell, oddly enough, is listening to the many thousands of direct requests its customers made during its big public brainstorm (aka IdeaStorm) not so far back. The result of nearly 70% of participants requesting Linux on Dell machines? Linux will soon be pre-installed on consumer desktops and laptops outside their server and Precision desktop lineup — hoorah! What we’re most curious about: when going to configure your system, how much money will one save by ducking out of the “Microsoft tax”? No word on when we’ll get to find out what the magic number is, but we imagine the Linux rollover won’t be immediate since Dell still has some serious work to do not only with the driver and software end of things to make future machines fully open-source, but also prepping and training its end-user support staff to get Linux-compatible, as it were.

[Via PC World]

I like this.

Massive Archive of free linux and programming books.
Hundreds of free books online covering a wide range of topics.

See this: Free linux and programming books.

roshco roast lf12 flasher box of pampers & luvs. xhilaration stockins red and white striped mud pie baby shoes www.gpx pills.com Customer contact for RCA camcorder squeak no more screws kit Mattel UNO Spin Hannah Montana electronic brand list bluewave water bottle Avon Ideal shade smooth mineral mineral makeup review motorola PREPAID refill sylvania light bulbs automotive reviews boho holiday dessert plates ladies cable knit gloves eztec radio control trains reviews barry's boot camp men izod crew socks 100% cashmere topcoat pittsburgh penguin car seat covers single load liquid laundry detergent how to connect a pantech matrix to the computer a christmas carol reginald owen colorized DVD collegiate crocs university of florida books aztec woman Music Wire - .047in OD, Spring Steel Music Wire, Straight ladies blouse bodysuit weedeater bv2000 gas blower junior fiesta ware spoon rest coby 7587 7 in. digital photo frame reviews littlest pet shop planner MAKITA T220D CORDLESS STAPLER Josephine Bib Aprons pinzon mandoline johnsons baby oil packaging sports magazines basketball instant immersion french v3.0 reviews windjammer window caulk Teen Hardcore porn free videos Exterior Accessories Shop Adult dating group fucking girl squirting hairy pussy BBW hardcore bisexual teen sex anime girls Online adult dating
© 2007 - 2021 Web Development | iKon Wordpress Theme by TextNData | Powered by Wordpress | rakCha web directory
XHTML CSS Links RSS

House mp3 music
Need help with money ? Let the experts help.