a parameter

the ioctl number

the file descriptor of the appropriate device file

The ioctl function is called with three parameters

Every device can have its own ioctl commands, which can be read ioctl's (to send information from a process to the kernel), write ioctl's (to return information to a process), [1] both or neither

The answer in Unix is to use a special function called ioctl

To create a new char device named `coffee' with major/minor number 12 and 2, simply do mknod /dev/coffee c 12 2

When the system was installed, all of those device files were created by the mknod command.

character devices are allowed to use as many or as few bytes as they like

block devices can only accept input and return output in blocks

This is important in the case of storage devices, where it's faster to read or write sectors which are close to each other,

block devices have a buffer

Devices are divided into two types: character devices and block devices

hey have unique minor numbers because the driver sees them as being different pieces of hardware.

The minor number is used by the driver to distinguish between the various hardware it controls.

The major number tells you which driver is used to access the hardware. Each driver is assigned a unique major number; all device files with the same major number are controlled by the same driver. All the above major numbers are 3, because they're all controlled by the same driver.

The first number is called the device's major number. The second number is the minor number.

3, 1

each piece of hardware is represented by a file located in /dev

One class of module is the device driver, which provides functionality for hardware like a TV card or a serial port

There are things called microkernels which have modules which get their own codespace.

the above discussion is true for any operating system which uses a monolithic kernel

it shares the kernel's codespace rather than having its own

Since a module is code which can be dynamically inserted and removed in the kernel

__init

your init and cleanup functions must be defined before calling the macros,

you can rename the init and cleanup functions of your modules; they no longer have to be called init_module() and cleanup_module() respectively. This is done with the module_init() and module_exit() macros

Change the return value to something negative,

Take a look at /var/log/messages

When the novelty wears off, remove your module from the kernel by using rmmod hello-1

simple Makefile

insert your freshly-compiled module it into the kernel with insmod ./hello-1.ko

they contain an additional .modinfo section that where additional information about the module is kept

kernel modules now have a .ko extension

there is a new way of doing

redundant settings accumulated in sublevel Makefiles

kbuild

(간단한 글은 여기를),

nML

HOL

If they want JavaScript, then it is an Ajax request and we render the JavaScript template associated with this action.

“if the client wants HTML in response to this action, just respond as we would have before, but if the client wants XML, return them the list of people in XML format.” (Rails determines the desired response format from the HTTP Accept header submitted by the client.)

You then have a corresponding app/views/users/create.js.erb

format.js

Notice the format.js in the respond_to block; that allows the controller to respond to your Ajax request.

Because the form's remote option is set to true, the request will be posted to the UsersController as an Ajax request, looking for JavaScript.

Ajax isn't just client-side, you also need to do some work on the server side to support it. Often, people like their Ajax requests to return JSON rather than HTML.

We call this 'unobtrusive' JavaScript because we're no longer mixing our JavaScript into our HTML. We've properly separated our concerns, making future change easy

would provide the @buyer object to the partial, available under the local variable account and is equivalent to:

:object option can be used to pass an object to the partial.

This would first render “advertiser/_account.html.erb” with @buyer passed in as the local variable account,

<%= render partial: "account", locals: { account: @buyer } %>

If you're not going to be using any of the options like collections or layouts, you can also use the short-hand defaults of render to render partials. Examples:

There's also a convenience method for rendering sub templates within the current controller that depends on a single object (we call this kind of sub templates for partials). It relies on the fact that partials should follow the naming convention of being prefixed with an underscore

However, Rails has a 'seeds' feature that should be used for seeding a database with initial data. It's a really simple feature: just fill up db/seeds.rb with some Ruby code, and run rake db:seed:

The Active Record way claims that intelligence belongs in your models, not in the database.

If you are using features like this, then you should set the schema format to :sql.

There is however a trade-off: db/schema.rb cannot express database specific items such as triggers, or stored procedures. While in a migration you can execute custom SQL statements, the schema dumper cannot reconstitute those statements from the database

Because this is database-independent, it could be loaded into any database that Active Record supports

:ruby

:sql or :ruby.

There are two ways to dump the schema.

the information is nicely summed up in the schema file.

Schema files are also useful if you want a quick look at what attributes an Active Record object has.

Migrations, mighty as they may be, are not the authoritative source for your database schema. That role falls to either db/schema.rb or an SQL file which Active Record generates by examining the database. They are not designed to be edited, they just represent the current state of the database.

Instead, you should write a new migration that performs the changes you require

In general, editing existing migrations is not a good idea.

Occasionally you will make a mistake when writing a migration. If you have already run the migration then you cannot just edit the migration and run the migration again: Rails thinks it has already run the migration and so will do nothing when you run rake db:migrate. You must rollback the migration (for example with rake db:rollback), edit your migration and then run rake db:migrate to run the corrected version.

rake db:drop

db:reset task will drop the database and set it up again

create the database, load the schema and initialize it with the seed data.

rake db:setup

If you specify a target version, Active Record will run the required migrations (change, up, down) until it has reached the specified version

runs the change or up method for all the migrations that have not yet been run

rake db:migrate.

You can also use the old style of migration using up and down methods

The revert method also accepts a block of instructions to reverse. This could be useful to revert selected parts of previous migrations.

If your migration is irreversible, you should raise ActiveRecord::IrreversibleMigration from your down method

reverse order

drop_table :distributors

create_table :distributors

the database schema should be unchanged if you do an up followed by a down

revert the transformations done by the up method.

down

describe the transformation you'd like to make to your schema

up

If the previous example migration is reverted, the down block will be run after the home_page_url column is removed and right before the table distributors is dropped.

Sometimes your migration will do something which is just plain irreversible; for example, it might destroy some data. In such cases, you can raise ActiveRecord::IrreversibleMigration in your down block.

If you're going to need to use any other methods, you should use reversible or write the up and down methods instead of using the change method.

he change method supports only these migration definitions

If the helpers provided by Active Record aren't enough you can use the execute method to execute arbitrary SQL

Active Record only supports single column foreign keys. execute and structure.sql are required to use composite foreign keys.

Unlike change_column (and change_column_default), change_column_null is reversible.

change_column_default

change_column_null

change_column

add_column

remove_column

A close cousin of create_table is change_table, used for changing existing tables. It is used in a similar fashion to create_table but the object yielded to the block knows more tricks.

which are not created by default)

which creates a categories_products table with two columns called category_id and product_id.

If you need to pass database specific options you can place an SQL fragment in the :options option

By default, create_table will create a primary key called id. You can change the name of the primary key with the :primary_key option

The create_table method is one of the most fundamental, but most of the time, will be generated for you from using a model or scaffold generator

The model and scaffold generators will create migrations appropriate for adding a new model.

There is also a generator which will produce join tables if JoinTable is part of the name:

the generator accepts column type as references(also available as belongs_to)

If the migration name is of the form "CreateXXX" and is followed by a list of column names and types then a migration creating the table XXX with the columns listed will be generated

part_number:string

If you'd like to add an index on the new column

If the migration name is of the form "AddXXXToYYY" or "RemoveXXXFromYYY" and is followed by a list of column names and types then a migration containing the appropriate add_column and remove_column statements will be created.

The name of the migration class (CamelCased version) should match the latter part of the file name.

Rails uses this timestamp to determine which migration should be run and in what order, so if you're copying a migration from another application or generate a file yourself, be aware of its position in the order.

Alternatively, you can use up and down instead of change:

If you wish for a migration to do something that Active Record doesn't know how to reverse, you can use reversible:

migrations are wrapped in a transaction

If the database does not support this then when a migration fails the parts of it that succeeded will not be rolled back. You will have to rollback the changes that were made by hand.

The timestamps macro adds two columns, created_at and updated_at.

A primary key column called id will also be added implicitly,

each migration modifies it to add or remove tables, columns, or entries.

migration as being a new 'version' of the database

Migrations are a convenient way to alter your database schema over time in a consistent and easy way

create_join_table does not create any indices by default;

The reference column is an integer by default

Rails keeps track of which files have been committed to the database and provides rollback features. To actually create the table, you'd run rake db:migrate and to roll it back, rake db:rollback.

migrations

Rails provides a domain-specific language for managing a database schema

This enables you to add behavior to your models by transparently executing code when those events occur, like when you create a new record, update it, destroy it and so on.

they raise the exception ActiveRecord::RecordInvalid if validation fails

save! and update!

return false when validation fails and they didn't actually perform any operation on the database

save and update take it into account when running

Active Record allows you to validate the state of a model before it gets written into the database.

destroyed

retrieved

update_all

you'd like to update several records in bulk

A shorthand for this

.update

saved

modified

.where(name: 'David', occupation: 'Code Artist')

.find_by(name: 'David')

.first

.all

create and new will yield the new object to that block for initialization:

block

user.save will commit the record to the database

create and save a new record into the database

create

instantiated without being saved

new

Active Record objects can be created from a hash, a block or have their attributes manually set after creation

ActiveRecord::Base.table_name= method

It's also possible to override the column that should be used as the table's primary key using the ActiveRecord::Base.primary_key= method:

If you do so, you will have to define manually the class name that is hosting the fixtures (my_products.yml) using the set_fixture_class method in your test definition

What if you need to follow a different naming convention or need to use your Rails application with a legacy database?

This will create a Product model, mapped to a products table at the database

While these column names are optional, they are in fact reserved by Active Record. Steer clear of reserved keywords unless you want the extra functionality.

created_at - Automatically gets set to the current date and time when the record is first created. updated_at - Automatically gets set to the current date and time whenever the record is updated. lock_version - Adds optimistic locking to a model. type - Specifies that the model uses Single Table Inheritance. (association_name)_type - Stores the type for polymorphic associations. (table_name)_count - Used to cache the number of belonging objects on associations. For example, a comments_count column in a Articles class that has many instances of Comment will cache the number of existent comments for each article.

Foreign keys - These fields should be named following the pattern singularized_table_name_id (e.g., item_id, order_id). These are the fields that Active Record will look for when you create associations between your models. Primary keys - By default, Active Record will use an integer column named id as the table's primary key. When using Active Record Migrations to create your tables, this column will be automatically created.

Database Table - Plural with underscores separating words (e.g., book_clubs). Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

Rails will pluralize your class names to find the respective database table. So, for a class Book, you should have a database table called books.

When writing applications using other programming languages or frameworks, it may be necessary to write a lot of configuration code. This is particularly true for ORM frameworks in general. However, if you follow the conventions adopted by Rails, you'll need to write very little configuration (in some case no configuration at all) when creating Active Record models.

Represent models and their data. Represent associations between these models. Represent inheritance hierarchies through related models. Validate models before they get persisted to the database. Perform database operations in an object-oriented fashion.

Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

is a technique that connects the rich objects of an application to tables in a relational database management system

Object-Relational Mapping,

Active Record takes the opinion that ensuring data access logic as part of the object will educate users of that object on how to write to and read from the database.

Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.

the layer of the system responsible for representing business data and logic

Active Record is the M in MVC

The render method here is taking a very simple hash with a key of plain and value of params[:article].inspect.

In the ArticlesController we need to have a way to block access to the various actions if the person is not authenticated. Here we can use the Rails http_basic_authenticate_with method, which allows access to the requested action if that method allows it.

As the render method iterates over the @article.comments collection, it assigns each comment to a local variable named the same as the partial,

<%= render @article.comments %>

In addition, the code takes advantage of some of the methods available for an association. We use the create method on @article.comments to create and save the comment. This will automatically link the comment so that it belongs to that particular article.

You'll see a bit more complexity here than you did in the controller for articles. That's a side-effect of the nesting that you've set up. Each request for a comment has to keep track of the article to which the comment is attached, thus the initial call to the find method of the Article model to get the article in question.

The form_for call here uses an array, which will build a nested route, such as /articles/1/comments.

form_for([@article, @article.comments.build])

if you have an instance variable @article containing an article, you can retrieve all the comments belonging to that article as an array using @article.comments.

We pass the named route as the second argument,

The delete routing method should be used for routes that destroy resources

Resource-oriented style.

The reason we can use this shorter, simpler form_for declaration to stand in for either of the other forms is that @article is a resource corresponding to a full set of RESTful routes, and Rails is able to infer which URI and method to use.

Our edit page looks very similar to the new page; in fact, they both share the same code for displaying the form. Let's remove this duplication by using a view partial. By convention, partial files are prefixed with an underscore.

You need to tell the user that something went wrong.

we use render instead of redirect_to when save returns false.

The new action is now creating a new instance variable called @article, and you'll see why that is in just a few moments.

redirect_to @article

With the validation now in place, when you call @article.save on an invalid article, it will return false

These changes will ensure that all articles have a title that is at least five characters long.

Article class inherits from ActiveRecord::Base. Active Record supplies a great deal of functionality to your Rails models for free, including basic database CRUD (Create, Read, Update, Destroy) operations, data validation, as well as sophisticated search support and the ability to relate multiple models to one another

link_to method is one of Rails' built-in view helpers.

:id tells rails that this route expects an :id parameter, which in our case will be the id of the article.

We have to whitelist our controller parameters to prevent wrongful mass assignment.

The ability to grab and automatically assign all controller parameters to your model in one shot makes the programmer's job easier, but this convenience also allows malicious use.

Rails has several security features that help you write secure applications, and you're running into one of them now. This one is called strong parameters, which requires us to tell Rails exactly which parameters are allowed into our controller actions.

You might be wondering why the A in Article.new is capitalized above, whereas most other references to articles in this guide have used lowercase. In this context, we are referring to the class named Article that is defined in \models\article.rb. Class names in Ruby must begin with a capital letter.

Then, @article.save is responsible for saving the model in the database. Finally, we redirect the user to the show action, which we'll define later.